date:20050421

On Thu, 2005-04-21 at 01:13 -0400, Robert Love wrote:

> Live from linux.conf.au, below is inotify against 2.6.12-rc3.

Here is an updated rediff for 2.6.12-rc3, with the changes from the last
day or so added:

- Add oneshot support for Tridge and Jeremy.
- Send IN_ATTRIB event on xattr change.
- Mark the open device as nonseekable.

Andrew, can you please replace the current inotify patch in 2.6-mm with
this?

Best,

Robert Love


inotify!

inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:

* dnotify requires the opening of one fd per each directory
  that you intend to watch. This quickly results in too many
  open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
  directories. Sure, a change to a file in a directory affects
  the directory, but you are then forced to keep a cache of
  stat structures.
* dnotify's interface to user-space is awful.  Signals?

inotify provides a more usable, simple, powerful solution to file change
notification:

* inotify's interface is a device node, not SIGIO.  You open a 
  single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
  you were watching is on was unmounted."
* inotify can watch directories or files.

Inotify is currently used by Beagle (a desktop search infrastructure),
Gamin (a FAM replacement), and other projects.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 Documentation/filesystems/inotify.txt |   81 ++
 fs/Kconfig|   13 
 fs/Makefile   |1 
 fs/attr.c |   33 -
 fs/compat.c   |   12 
 fs/file_table.c   |3 
 fs/inode.c|6 
 fs/inotify.c  |  965 ++
 fs/namei.c|   30 -
 fs/open.c |4 
 fs/read_write.c   |   15 
 fs/xattr.c|5 
 include/linux/fs.h|6 
 include/linux/fsnotify.h  |  230 
 include/linux/inotify.h   |  112 +++
 include/linux/sched.h |4 
 kernel/user.c |4 
 17 files changed, 1468 insertions(+), 56 deletions(-)

diff -urN linux-2.6.12-rc3/Documentation/filesystems/inotify.txt 
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc3/Documentation/filesystems/inotify.txt  1969-12-31 
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-22 00:48:39.0 
-0400
@@ -0,0 +1,81 @@
+   inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <[EMAIL PROTECTED]>
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify.  If you do not use udev,
+this device may need to be created manually.  First step, open it
+
+   int dev_fd = open ("/dev/inotify", O_RDONLY);
+
+Change events are managed by "watches".  A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive.  See 
+for valid events.  A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+   /* 'wd' represents the watch on fd with mask */
+   struct inotify_request req = { fd, mask };
+   int wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+You can add a large number of files via something like
+
+   for each file to watch {
+   struct inotify_request req;
+   int file_fd;
+
+   file_fd = open (file, O_RDONLY);
+   if (fd < 0) {
+   perror ("open");
+   break;
+   }
+
+   req.fd = file_fd;
+   req.mask = mask;
+
+   wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+   close (fd);
+   }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+   ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from /dev/inotify.  The filename is of dynamic length and follows the struct.
+It is of size len.  The filename is padded with null bytes to ensure proper
+alignment.  This padding is reflected in len.
+
+You can slurp multiple events by passing a large buffer, for example
+
+   size_t len = read

Re: [patch] inotify for 2.6.12-rc3.

On Thu, 2005-04-21 at 01:13 -0400, Robert Love wrote:

> Live from linux.conf.au, below is inotify against 2.6.12-rc3.

Mark the open inotify device as nonseekable, so lseek() and such do not
work.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 fs/inotify.c |2 ++
 1 files changed, 2 insertions(+)

diff -urN linux-2.6.12-rc3-inotify/fs/inotify.c linux/fs/inotify.c
--- linux-2.6.12-rc3-inotify/fs/inotify.c   2005-04-22 00:54:25.0 
-0400
+++ linux/fs/inotify.c  2005-04-22 00:50:36.0 -0400
@@ -743,6 +743,8 @@
 
file->private_data = dev;
 
+   nonseekable_open(inode, file);
+
return 0;
 out_err:
free_uid(user);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Clean-up and bug fix for tdfxfb framebuffer size detection

2005-04-21 Thread Richard Drummond

Attached is a patch against 2.6.11.7 which tidies up the tdfxfb framebuffer 
size detection code a little and fixes the broken support for Voodoo4/5 cards. 
(I haven't tested this on a Voodoo5, however, because I don't have the 
hardware).

Signed-off-by: Richard Drummond <[EMAIL PROTECTED]>
--- drivers/video/tdfxfb.c_orig	2005-04-20 15:04:23.0 -0500
+++ drivers/video/tdfxfb.c	2005-04-21 22:20:32.0 -0500
@@ -414,36 +414,35 @@
 
 static unsigned long do_lfb_size(struct tdfx_par *par, unsigned short dev_id) 
 {
-	u32 draminit0 = 0;
-	u32 draminit1 = 0;
-	u32 miscinit1 = 0;
-	u32 lfbsize   = 0;
-	int sgram_p   = 0;
+	u32 draminit0;
+	u32 draminit1;
+	u32 miscinit1;
+
+	int num_chips;
+	int chip_size; /* in MB */
+	u32 lfbsize;
+	int has_sgram;
 
 	draminit0 = tdfx_inl(par, DRAMINIT0);  
 	draminit1 = tdfx_inl(par, DRAMINIT1);
+   
+	num_chips = (draminit0 & DRAMINIT0_SGRAM_NUM) ? 8 : 4;
  
-	if ((dev_id == PCI_DEVICE_ID_3DFX_BANSHEE) ||
-	(dev_id == PCI_DEVICE_ID_3DFX_VOODOO3)) { 	 
-		sgram_p = (draminit1 & DRAMINIT1_MEM_SDRAM) ? 0 : 1;
-  
-	lfbsize = sgram_p ?
-		(((draminit0 & DRAMINIT0_SGRAM_NUM)  ? 2 : 1) * 
-		((draminit0 & DRAMINIT0_SGRAM_TYPE) ? 8 : 4) * 1024 * 1024) :
-		16 * 1024 * 1024;
+	if (dev_id < PCI_DEVICE_ID_3DFX_VOODOO5) {
+		/* Banshee/Voodoo3 */
+		has_sgram = draminit1 & DRAMINIT1_MEM_SDRAM;	   
+		chip_size = has_sgram ? ((draminit0 & DRAMINIT0_SGRAM_TYPE) ? 2 : 1)
+  : 2;
 	} else {
 		/* Voodoo4/5 */
-		u32 chips, psize, banks;
+		has_sgram = 0;
+		chip_size = 1 << ((draminit0 & DRAMINIT0_SGRAM_TYPE_MASK) >> DRAMINIT0_SGRAM_TYPE_SHIFT);
+	}
+	lfbsize = num_chips * chip_size * 1024 * 1024;
 
-		chips = ((draminit0 & (1 << 26)) == 0) ? 4 : 8;
-		psize = 1 << ((draminit0 & 0x3800) >> 28);
-		banks = ((draminit0 & (1 << 30)) == 0) ? 2 : 4;
-		lfbsize = chips * psize * banks;
-		lfbsize <<= 20;
-	} 
-	/* disable block writes for SDRAM (why?) */
+	/* disable block writes for SDRAM */
 	miscinit1 = tdfx_inl(par, MISCINIT1);
-	miscinit1 |= sgram_p ? 0 : MISCINIT1_2DBLOCK_DIS;
+	miscinit1 |= has_sgram ? 0 : MISCINIT1_2DBLOCK_DIS;
 	miscinit1 |= MISCINIT1_CLUT_INV;
 
 	banshee_make_room(par, 1); 
--- include/video/tdfx.h_orig	2005-04-21 21:16:56.0 -0500
+++ include/video/tdfx.h	2005-04-21 09:39:42.0 -0500
@@ -99,6 +99,8 @@
 #define MISCINIT1_2DBLOCK_DIS   BIT(15)
 #define DRAMINIT0_SGRAM_NUM BIT(26)
 #define DRAMINIT0_SGRAM_TYPEBIT(27)
+#define DRAMINIT0_SGRAM_TYPE_MASK   (BIT(27)|BIT(28)|BIT(29))
+#define DRAMINIT0_SGRAM_TYPE_SHIFT  27
 #define DRAMINIT1_MEM_SDRAM BIT(30)
 #define VGAINIT0_VGA_DISABLEBIT(0)
 #define VGAINIT0_EXT_TIMING BIT(1)

[PATCH] Better PLL frequency matching for tdfxfb driver

2005-04-21 Thread Richard Drummond

Attached is a patch against 2.6.11.7 which improves the PLL frequency matching 
in the tdfxfb driver. Instead of requiring 64260 iterations to obtain the 
closest supported PLL frequency, this code does it with the same degree of 
accuracy in at most 768 iterations.

Signed-off-by: Richard Drummond <[EMAIL PROTECTED]>
--- drivers/video/tdfxfb.c_orig	2005-04-20 15:04:23.0 -0500
+++ drivers/video/tdfxfb.c	2005-04-21 09:26:18.0 -0500
@@ -320,30 +320,40 @@
 
 static u32 do_calc_pll(int freq, int* freq_out) 
 {
-	int m, n, k, best_m, best_n, best_k, f_cur, best_error;
+	int m, n, k, best_m, best_n, best_k, best_error;
 	int fref = 14318;
   
-	/* this really could be done with more intelligence --
-	   255*63*4 = 64260 iterations is silly */
 	best_error = freq;
 	best_n = best_m = best_k = 0;
-	for (n = 1; n < 256; n++) {
-		for (m = 1; m < 64; m++) {
-			for (k = 0; k < 4; k++) {
-f_cur = fref*(n + 2)/(m + 2)/(1 << k);
-if (abs(f_cur - freq) < best_error) {
-	best_error = abs(f_cur-freq);
-	best_n = n;
-	best_m = m;
-	best_k = k;
-}
+   
+	for (k = 3; k >= 0; k--) {	
+		for (m = 63; m >= 0; m--) {
+			/* Estimate value of n that produces target frequency with current m and k */
+			int n_estimated = (freq * (m + 2) * (1 << k) / fref) - 2;
+	 
+			/* Search neighborhood of estimated n */
+			for (n = max(0, n_estimated - 1); n <= min(255, n_estimated + 1); n++) {
+/* Calculate PLL freqency with current m, k and estimated n */
+int f = fref * (n + 2) / (m + 2) / (1 << k);
+int error = abs (f - freq);
+		  
+/* If this is the closest we've come to the target frequency
+ * then remember n, m and k */
+if (error  < best_error) {
+	best_error = error;
+	best_n = n;
+	best_m = m;
+	best_k = k;
+}  
 			}
 		}
 	}
+   
 	n = best_n;
 	m = best_m;
 	k = best_k;
 	*freq_out = fref*(n + 2)/(m + 2)/(1 << k);
+   
 	return (n << 8) | (m << 2) | k;
 }

Re: [patch 1/2] kstrdup: implementation

On Fri, 2005-04-22 at 05:51 +0200, Adrian Bunk wrote:

> This is a good example why development against Linus' tree is ofter 
> pointless:

Seriously.

> A similar patch is already in -mm.

But...woohoo!

Robert Love


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/2] kstrdup: implementation

2005-04-21 Thread Adrian Bunk

On Thu, Apr 21, 2005 at 11:41:15PM -0400, Robert Love wrote:

> Rusty and I's LCA kernel tutorial again brought up kstrdup().  Let's
> close this never ending saga and provide a standard kernel
> implementation.
>...

This is a good example why development against Linus' tree is ofter 
pointless:

A similar patch is already in -mm.

> Best,
> 
>   Robert Love
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/2] kstrdup: replace a few


> Rusty and I's LCA kernel tutorial again brought up kstrdup().  Let's
> close this never ending saga and provide a standard kernel
> implementation.

Convert a few existing implementations, with a nice net loss of 50
lines.  Still way more to go.

Best,

Robert Love


Convert a bunch of strdup() implementations and their callers to the new
kstrdup().  A few remain, for example see sound/core, and there are tons of
open coded strdup()'s around.  Sigh.  But this is a start.

By: Robert Love and Rusty Russell.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 arch/um/kernel/process_kern.c |8 ++--
 drivers/md/dm-ioctl.c |   17 +++--
 drivers/parport/probe.c   |   18 +-
 include/linux/netdevice.h |4 
 net/core/neighbour.c  |2 +-
 net/core/sysctl_net_core.c|   15 ---
 net/ipv4/devinet.c|2 +-
 net/ipv6/addrconf.c   |2 +-
 net/sunrpc/svcauth_unix.c |   11 ++-
 9 files changed, 15 insertions(+), 64 deletions(-)

diff -urN linux-2.6.12-rc3/arch/um/kernel/process_kern.c 
linux/arch/um/kernel/process_kern.c
--- linux-2.6.12-rc3/arch/um/kernel/process_kern.c  2005-04-20 
22:47:00.0 -0400
+++ linux/arch/um/kernel/process_kern.c 2005-04-21 21:51:38.0 -0400
@@ -8,6 +8,7 @@
 #include "linux/kernel.h"
 #include "linux/sched.h"
 #include "linux/interrupt.h"
+#include "linux/string.h"
 #include "linux/mm.h"
 #include "linux/slab.h"
 #include "linux/utsname.h"
@@ -356,12 +357,7 @@
 
 char *uml_strdup(char *string)
 {
-   char *new;
-
-   new = kmalloc(strlen(string) + 1, GFP_KERNEL);
-   if(new == NULL) return(NULL);
-   strcpy(new, string);
-   return(new);
+   return kstrdup(string, GFP_KERNEL);
 }
 
 void *get_init_task(void)
diff -urN linux-2.6.12-rc3/drivers/md/dm-ioctl.c linux/drivers/md/dm-ioctl.c
--- linux-2.6.12-rc3/drivers/md/dm-ioctl.c  2005-03-02 02:37:51.0 
-0500
+++ linux/drivers/md/dm-ioctl.c 2005-04-21 21:46:15.0 -0400
@@ -119,17 +119,6 @@
return NULL;
 }
 
-/*-
- * Inserting, removing and renaming a device.
- *---*/
-static inline char *kstrdup(const char *str)
-{
-   char *r = kmalloc(strlen(str) + 1, GFP_KERNEL);
-   if (r)
-   strcpy(r, str);
-   return r;
-}
-
 static struct hash_cell *alloc_cell(const char *name, const char *uuid,
struct mapped_device *md)
 {
@@ -139,7 +128,7 @@
if (!hc)
return NULL;
 
-   hc->name = kstrdup(name);
+   hc->name = kstrdup(name, GFP_KERNEL);
if (!hc->name) {
kfree(hc);
return NULL;
@@ -149,7 +138,7 @@
hc->uuid = NULL;
 
else {
-   hc->uuid = kstrdup(uuid);
+   hc->uuid = kstrdup(uuid, GFP_KERNEL);
if (!hc->uuid) {
kfree(hc->name);
kfree(hc);
@@ -273,7 +262,7 @@
/*
 * duplicate new.
 */
-   new_name = kstrdup(new);
+   new_name = kstrdup(new, GFP_KERNEL);
if (!new_name)
return -ENOMEM;
 
diff -urN linux-2.6.12-rc3/drivers/parport/probe.c linux/drivers/parport/probe.c
--- linux-2.6.12-rc3/drivers/parport/probe.c2005-04-20 22:47:04.0 
-0400
+++ linux/drivers/parport/probe.c   2005-04-21 21:45:39.0 -0400
@@ -48,14 +48,6 @@
printk("\n");
 }
 
-static char *strdup(char *str)
-{
-   int n = strlen(str)+1;
-   char *s = kmalloc(n, GFP_KERNEL);
-   if (!s) return NULL;
-   return strcpy(s, str);
-}
-
 static void parse_data(struct parport *port, int device, char *str)
 {
char *txt = kmalloc(strlen(str)+1, GFP_KERNEL);
@@ -88,16 +80,16 @@
if (!strcmp(p, "MFG") || !strcmp(p, "MANUFACTURER")) {
if (info->mfr)
kfree (info->mfr);
-   info->mfr = strdup(sep);
+   info->mfr = kstrdup(sep, GFP_KERNEL);
} else if (!strcmp(p, "MDL") || !strcmp(p, "MODEL")) {
if (info->model)
kfree (info->model);
-   info->model = strdup(sep);
+   info->model = kstrdup(sep, GFP_KERNEL);
} else if (!strcmp(p, "CLS") || !strcmp(p, "CLASS")) {
int i;
if (info->class_name)
kfree (info->class_name);
-   info->class_name = strdup(sep);
+   info->class_name = kstrdup(sep, GFP_KERNEL);
for (u = sep; *u; u++)

[patch 1/2] kstrdup: implementation

Rusty and I's LCA kernel tutorial again brought up kstrdup().  Let's
close this never ending saga and provide a standard kernel
implementation.

As an example of the savings from such a patch, there are a handful of
existing strdup() implementations and what looks like 100s of open coded
strdup() uses.  Some of which are surely buggy or less optimal than our
version, and all of which bloat the kernel.

Andrew, patch is against 2.6.12-rc3.

Best,

Robert Love


The world continually reimplements kstrdup().  Implement an optimal version
and export it to the world.

By: Robert Love and Rusty Russell.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 include/linux/string.h |1 +
 lib/string.c   |   20 
 2 files changed, 21 insertions(+)

diff -urN linux-2.6.12-rc3/include/linux/string.h linux/include/linux/string.h
--- linux-2.6.12-rc3/include/linux/string.h 2005-03-02 02:38:07.0 
-0500
+++ linux/include/linux/string.h2005-04-21 21:23:04.0 -0400
@@ -17,6 +17,7 @@
 extern char * strsep(char **,const char *);
 extern __kernel_size_t strspn(const char *,const char *);
 extern __kernel_size_t strcspn(const char *,const char *);
+extern char * kstrdup(const char *,unsigned int __nocast);
 
 /*
  * Include machine specific inline routines
diff -urN linux-2.6.12-rc3/lib/string.c linux/lib/string.c
--- linux-2.6.12-rc3/lib/string.c   2005-03-02 02:38:25.0 -0500
+++ linux/lib/string.c  2005-04-21 21:31:11.0 -0400
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifndef __HAVE_ARCH_STRNICMP
@@ -76,6 +77,25 @@
 EXPORT_SYMBOL(strcpy);
 #endif
 
+/*
+ * kstrdup - allocate space for and then copy an existing string
+ *
+ * @str: the string to duplicate
+ * @gfp: the GFP mask used to allocate the storage for the duplicated string
+ */
+char * kstrdup(const char *str, unsigned int __nocast flags)
+{
+   size_t len;
+   char *buf;
+
+   len = strlen(str) + 1;
+   buf = kmalloc(len, flags);
+   if (likely(buf))
+   memcpy(buf, str, len);
+   return buf;
+}
+EXPORT_SYMBOL(kstrdup);
+
 #ifndef __HAVE_ARCH_STRNCPY
 /**
  * strncpy - Copy a length-limited, %NUL-terminated string


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread David A. Wheeler

Petr Baudis <[EMAIL PROTECTED]> writes:
Still, why would you escape it? My shell will not take # as a
comment start if it is immediately after an alphanumeric character.
I guess there MIGHT be some command shell implementation
that stupidly _DID_ accept "#" as a comment character,
even immediately after an alphanumeric.
If that's true, then using # there would be a pain for portability.
But I think that's highly improbable.  A quick peek
at the Single Unix Specification as posted by the Open Group
seems to say that, according to the standards, that's NOT okay:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02
Basically, the command shell is supposed to tokenize, and "#"
only means comment if it's at the beginning of a token.
And as far as I can tell, it's not an issue in practice either.
I did a few quick tests on Fedora Core 3 and OpenBSD.
On Fedora Core 3, I can say that bash, ash & csh all do NOT
consider "#" as a comment start if an alpha precedes it.
The same is true for OpenBSD /bin/sh, /bin/csh, and /bin/rksh.
If such different shells do the same thing (this stuff isn't even
legal C-shell text!), it's likely others do too.
--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]

2005-04-21 Thread Edgar Toernig

On Thu, 21 Apr 2005, Chris Friesen wrote:
>
> Does mainline have a high precision monotonic wallclock that is not 
> affected by time-of-day changes?  Something like "nano/mico seconds 
> since boot"?

On newer kernels with the posix timers (I think 2.6 - not sure though)
there's clock_gettime(CLOCK_MONOTONIC, ...).

Linus Torvalds wrote:
>
> Getting "approximate uptime" really really _really_ fast
> might be useful for some things, but I don't know how many.

I bet most users of gettimeofday actually want a strictly monotonic
increasing clock where the actual base time is irrelevant.  Just strace
some apps - those issuing hundreds and thousands of gettimeofday calls
are most likely in this class.  Those who only call gettimeofday once
or twice or the ones that really want the wall clock time.

How often does the kernel use jiffies (the monotonic clock) and how often
xtime (the wall clock)?

Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux Kernel

2005-04-21 Thread Marcondes Monteiro de Arau

Hi!

I'm university student in Brazil and would like to know if during the process 
of compilation of the kernel of the linux the tecnology of cluster is used.



Marcondes

-- 
___
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] unregister_node() for hotplug use

2005-04-21 Thread Keiichiro Tokunaga

On Thu, 21 Apr 2005 17:39:20 -0700 Greg KH wrote:
> On Fri, Apr 22, 2005 at 12:30:09AM +0900, Keiichiro Tokunaga wrote:
> > +#ifdef CONFIG_HOTPLUG
> > +void unregister_node(struct node *node)
> > +{
> > +   sysdev_remove_file(>sysdev, _cpumap);
> > +   sysdev_remove_file(>sysdev, _meminfo);
> > +   sysdev_remove_file(>sysdev, _numastat);
> > +   sysdev_remove_file(>sysdev, _distance);
> > +
> > +   sysdev_unregister(>sysdev);
> > +}
> > +EXPORT_SYMBOL_GPL(register_node);
> > +EXPORT_SYMBOL_GPL(unregister_node);
> > +#else /* !CONFIG_HOTPLUG */
> > +void unregister_node(struct node *node)
> > +{
> > +}
> > +#endif /* !CONFIG_HOTPLUG */
> 
> Oops, you only exported the symbols if CONFIG_HOTPLUG is enabled, not a
> good idea.  Either make the null functions in a .h file if the option is
> not enabled, or always export them.

  My bad...

> And the comment for the #endif isn't really needed, as the whole #ifdef
> fits on a single screen :)

  I see:)  That makes sense.

> And hey, what's the real big deal here, why not always have this
> function no matter if CONFIG_HOTPLUG is enabled or not?  I really want
> to just make that an option that is always enabled anyway, but changable
> if you are using CONFIG_TINY or something...

  I put the #ifdef there for users who don't need hotplug
stuffs, but I want to make the option always enabled, too.
Also a good side effect, the code would be cleaner:)  I
will be updating my patch without the #ifdef and sending
it here.

Thanks!
Keiichiro Tokunaga
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

x86-64 dual core mapping

2005-04-21 Thread YhLu

Andi,

I tried 2.6.12-rc3 with dual way dual cpus.

It seems right mapping should be
CPU 0(2) -> Node 0 -> Core 0
CPU 1(2) -> Node 0 -> Core 1
CPU 2(2) -> Node 1 -> Core 0
CPU 3(2) -> Node 1 -> Core 1

instead of

CPU 0(2) -> Node 0 -> Core 0
CPU 1(2) -> Node 0 -> Core 0
CPU 2(2) -> Node 1 -> Core 1
CPU 3(2) -> Node 1 -> Core 1

YH




CPU 0(2) -> Node 0 -> Core 0
Using local APIC NMI watchdog using perfctr0
enabled ExtINT on CPU#0
ENABLING IO-APIC IRQs
Using IO-APIC 4
...changing IO-APIC physical APIC ID to 4 ... ok.
Using IO-APIC 5
...changing IO-APIC physical APIC ID to 5 ... ok.
Using IO-APIC 6
...changing IO-APIC physical APIC ID to 6 ... ok.
Using IO-APIC 7
...changing IO-APIC physical APIC ID to 7 ... ok.
Synchronizing Arb IDs.
..TIMER: vector=0x31 pin1=0 pin2=2
testing the IO APIC...




 done.
Using local APIC timer interrupts.
Detected 12.564 MHz APIC timer.
Booting processor 1/1 rip 6000 rsp 81007ff99f58
Initializing CPU#1
masked ExtINT on CPU#1
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(2) -> Node 0 -> Core 0
 stepping 00
Synced TSC of CPU 1 difference 30064769976
Booting processor 2/2 rip 6000 rsp 81013ffa3f58
Initializing CPU#2
masked ExtINT on CPU#2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 2(2) -> Node 1 -> Core 1
 stepping 00
Synced TSC of CPU 2 difference 30064770021
Booting processor 3/3 rip 6000 rsp 81007ff49f58
Initializing CPU#3
masked ExtINT on CPU#3
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 3(2) -> Node 1 -> Core 1
 stepping 00
Synced TSC of CPU 3 difference 30064770021
Brought up 4 CPUs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread Inaky Perez-Gonzalez

> Petr Baudis <[EMAIL PROTECTED]> writes:

> Remember that it's an URL (so you can't use '%'), and '#' is the
> canonical URL fragment identifier delimiter. (And fragments are
> perfect for this kind of thing, if you look at the RFC, BTW.)

Ouch, true--rule out %...

> Still, why would you escape it? My shell will not take # as a
> comment start if it is immediately after an alphanumeric character.

Well, you just taught me something about bash I didn't know

/me goes back to his hole with some more knowledge.

Thanks,

-- 

Inaky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

Dear diary, on Fri, Apr 22, 2005 at 03:48:35AM CEST, I got a letter
where Inaky Perez-Gonzalez <[EMAIL PROTECTED]> told me that...
> > Petr Baudis <[EMAIL PROTECTED]> writes:
> 
> > I've just added to git-pasky a possibility to refer to branches
> > inside of repositories by a fragment identifier:
> 
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing
> 
> > will refer to your testing branch in that repository.
> 
> Can we use something other than #? we'll have to scape it all the time
> in the shell (or at least also allow some other char, something
> without special meta-character meaning in the shell, like %).

Remember that it's an URL (so you can't use '%'), and '#' is the
canonical URL fragment identifier delimiter. (And fragments are perfect
for this kind of thing, if you look at the RFC, BTW.)

Still, why would you escape it? My shell will not take # as a comment
start if it is immediately after an alphanumeric character.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread Inaky Perez-Gonzalez

> Petr Baudis <[EMAIL PROTECTED]> writes:

> I've just added to git-pasky a possibility to refer to branches
> inside of repositories by a fragment identifier:

> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing

> will refer to your testing branch in that repository.

Can we use something other than #? we'll have to scape it all the time
in the shell (or at least also allow some other char, something
without special meta-character meaning in the shell, like %).

-- 

Inaky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

Dear diary, on Fri, Apr 22, 2005 at 01:01:13AM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> But now I need a way to indicate to consumers of the public shared object
> data base which HEAD to use.
> 
> Perhaps I should just say "merge 821376bf15e692941f9235f13a14987009fd0b10
> from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git"?

I've just added to git-pasky a possibility to refer to branches inside
of repositories by a fragment identifier:

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing

will refer to your testing branch in that repository.

HTH,

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3:microtek.c:338: error: for each function it appears in.

2005-04-21 Thread Bob Gill

OK.  I downloaded, patched and started the build.  Basically everything
stops when I get a "microtek.c:338: error: `FAILURE' undeclared" error
(the build keeps trying, but no modules get created).  
I suspect others may have the same problem, but feel free to e-mail me
for more information (and you will have to as I am not on the list).
...ok, also I have tried adding 
 #define MTS_SCSI_ERR_MASK ~0x3fu
>#define FAILURE   ~0x3fu
on line 55 of microtek.h ...basically a copycat of the previous error
line...(but I suspect the kernel maintainer would be a better person to
define FAILURE somewhere...)
And...it does boot and I can
taint.the.kernel.with.nvidia.video

TIA,
Bob
-- 
Bob Gill <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sync_page() smp_mb() comment

2005-04-21 Thread William Lee Irwin III

The smp_mb() is becaus sync_page() doesn't have PG_locked while it
accesses page_mapping(page). The comments in the patch (the entire
patch is the addition of this comment) try to explain further how
and why smp_mb() is used.


mm/filemap.c: 93595c327bbdc43fcea91b513fd750d1a73edfec
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -139,7 +139,25 @@ static int sync_page(void *word)
page = container_of((page_flags_t *)word, struct page, flags);
 
/*
-* FIXME, fercrissake.  What is this barrier here for?
+* page_mapping() is being called without PG_locked held.
+* Some knowledge of the state and use of the page is used to
+* reduce the requirements down to a memory barrier.
+* The danger here is of a stale page_mapping() return value
+* indicating a struct address_space different from the one it's
+* associated with when it is associated with one.
+* After smp_mb(), it's either the correct page_mapping() for
+* the page, or an old page_mapping() and the page's own
+* page_mapping() has gone NULL.
+* The ->sync_page() address_space operation must tolerate
+* page_mapping() going NULL. By an amazing coincidence,
+* this comes about because none of the users of the page
+* in the ->sync_page() methods make essential use of the
+* page_mapping(), merely passing the page down to the backing
+* device's unplug functions when it's non-NULL, which in turn
+* ignore it for all cases but swap, where only page->private is
+* of interest. When page_mapping() does go NULL, the entire
+* call stack gracefully ignores the page and returns.
+* -- wli
 */
smp_mb();
mapping = page_mapping(page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Git-commits mailing list feed.

On Thu, Apr 21, 2005 at 08:24:36AM +0200, Jan Dittmer wrote:
> David Woodhouse wrote:
> > As of some time in the fairly near future, the [EMAIL PROTECTED] mailing 
> > list will be carrying real commits from Linus' live git repository, instead
> > of just testing patches. Have fun.
> > 
> 
> What about the daily snapshots? Is there any eta when they'll be back?

The script that generated this was posted previously on lkml.  If anyone
wants to hack that up to generate the snapshots, it would be greatly
appreciated.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] unregister_node() for hotplug use

On Fri, Apr 22, 2005 at 12:30:09AM +0900, Keiichiro Tokunaga wrote:
> +#ifdef CONFIG_HOTPLUG
> +void unregister_node(struct node *node)
> +{
> + sysdev_remove_file(>sysdev, _cpumap);
> + sysdev_remove_file(>sysdev, _meminfo);
> + sysdev_remove_file(>sysdev, _numastat);
> + sysdev_remove_file(>sysdev, _distance);
> +
> + sysdev_unregister(>sysdev);
> +}
> +EXPORT_SYMBOL_GPL(register_node);
> +EXPORT_SYMBOL_GPL(unregister_node);
> +#else /* !CONFIG_HOTPLUG */
> +void unregister_node(struct node *node)
> +{
> +}
> +#endif /* !CONFIG_HOTPLUG */

Oops, you only exported the symbols if CONFIG_HOTPLUG is enabled, not a
good idea.  Either make the null functions in a .h file if the option is
not enabled, or always export them.

And the comment for the #endif isn't really needed, as the whole #ifdef
fits on a single screen :)

And hey, what's the real big deal here, why not always have this
function no matter if CONFIG_HOTPLUG is enabled or not?  I really want
to just make that an option that is always enabled anyway, but changable
if you are using CONFIG_TINY or something...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lirc and Linux 2.6.11

On Thu, Apr 21, 2005 at 03:26:37PM -0700, Shaun Jackman wrote:
> I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
> 2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
> the new kernel. This did not work. I then tried compiling the lirc
> 0.7.1 modules for the new kernel. This didn't work either. The error
> message lircd gives is...
> 
> Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
> Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
> Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
> Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
> Apr 21 14:57:52 quince lircd 0.7.1: caught signal
> 
> I've also asked the lirc mailing list this question, but has anyone
> else run into this trouble with lirc and Linux 2.6.11?

As the lirc developers have no intention of ever merging with the
mainline kernel code, you will have to ask all lirc questions to them,
we can not help you out at all, sorry.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

On Thu, Apr 21, 2005 at 03:33:42PM +0200, Andreas Steinmetz wrote:
> Compile error on x86_64:
> 
>   CC [M]  drivers/usb/image/microtek.o
> drivers/usb/image/microtek.c: In function `mts_scsi_abort':
> drivers/usb/image/microtek.c:338: error: `FAILURE' undeclared (first use
> in this function)

Patch to fix this was posted on lkml and is in my queue to send to Linus
in a bit.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 7/10] tg3: more use of TG3_FLG2_5705_PLUS flag

On Wed, 13 Apr 2005 19:38:45 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Rewrite of a couple of troublesome multi-way if statements to use
> TG3_FLG2_5705_PLUS flag.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86_64: Bug in new out of line put_user()

2005-04-21 Thread Brian Gerst

Alexander Nyberg wrote:
The new out of line put_user() assembly on x86_64 changes %rcx without
telling GCC about it causing things like:
http://bugme.osdl.org/show_bug.cgi?id=4515 

See to it that %rcx is not changed (made it consistent with get_user()).
Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
Index: test/arch/x86_64/lib/getuser.S
===
--- test.orig/arch/x86_64/lib/getuser.S	2005-04-20 23:55:35.0 +0200
+++ test/arch/x86_64/lib/getuser.S	2005-04-21 00:54:16.0 +0200
@@ -78,9 +78,9 @@
 __get_user_8:
 	GET_THREAD_INFO(%r8)
 	addq $7,%rcx
-	jc bad_get_user
+	jc 40f
 	cmpq threadinfo_addr_limit(%r8),%rcx
-	jae	bad_get_user
+	jae	40f
 	subq	$7,%rcx
 4:	movq (%rcx),%rdx
 	xorl %eax,%eax
Index: test/arch/x86_64/lib/putuser.S
===
--- test.orig/arch/x86_64/lib/putuser.S	2005-04-21 00:50:24.0 +0200
+++ test/arch/x86_64/lib/putuser.S	2005-04-21 01:02:15.0 +0200
@@ -46,36 +46,45 @@
 __put_user_2:
 	GET_THREAD_INFO(%r8)
 	addq $1,%rcx
-	jc bad_put_user
+	jc 20f
 	cmpq threadinfo_addr_limit(%r8),%rcx
-	jae	 bad_put_user
-2:	movw %dx,-1(%rcx)
+	jae 20f
+2:	decq %rcx
+	movw %dx,(%rcx)
 	xorl %eax,%eax
 	ret
+20:	decq %rcx
+	jmp bad_put_user
 
 	.p2align 4
 .globl __put_user_4
 __put_user_4:
 	GET_THREAD_INFO(%r8)
 	addq $3,%rcx
-	jc bad_put_user
+	jc 30f
 	cmpq threadinfo_addr_limit(%r8),%rcx
-	jae bad_put_user
-3:	movl %edx,-3(%rcx)
+	jae 30f
+3:	subq $3,%rcx
+	movl %edx,(%rcx)
 	xorl %eax,%eax
 	ret
+30:	subq $3,%rcx
+	jmp bad_put_user
 
 	.p2align 4
 .globl __put_user_8
 __put_user_8:
 	GET_THREAD_INFO(%r8)
 	addq $7,%rcx
-	jc bad_put_user
+	jc 40f
 	cmpq threadinfo_addr_limit(%r8),%rcx
-	jae	bad_put_user
-4:	movq %rdx,-7(%rcx)
+	jae 40f
+4:	subq $7,%rcx
+	movq %rdx,(%rcx)
 	xorl %eax,%eax
 	ret
+40:	subq $7,%rcx
+	jmp bad_put_user
 
 bad_put_user:
 	movq $(-EFAULT),%rax

-
This patch has a serious bug.  The 2, 3 and 4 labels must be on the mov 
instructions in order to catch faults.

--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread Bernd Eckenfels

In article <[EMAIL PROTECTED]> you wrote:
> Why? Because I'm still using the stupid "get all objects" thing when I
> pull.

one could do a symlink/hardlink parallel tree for a specific snapshot with
GIT tools, and then only poll that with git-unaware copy tools.

I guess this would make sense for the most common kernel development lines.

Another improvement would be to add a "secondary storage fetch" script, so
the git tools can, if they cant find a object by hash just query an external
pool. In combination with the above this will allow users to compare progress.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Dear diary, on Fri, Apr 22, 2005 at 01:22:01AM CEST, I got a letter
where Pavel Machek <[EMAIL PROTECTED]> told me that...
> Hi!

Hi,

> > > > You should put this into .git/remotes
> > > > 
> > > > linus   
> > > > rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > 
> > (git addremote is preferred for that :-)
> 
> Nice, so I now have my own -git tree, with two changes in it...
> 
> Is there way to say "git diff -r origin:" but dump it patch-by-patch
> with some usable headers?
> 
> [Looking at git export]

Either Linus' demo git-export (NOT the same as git export!), or git
patch. In the latest tree, it was extended to accept a range of two
commits to process too.

Note that the range semantics is rather peculiar at the least. ;-)

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

Dear diary, on Fri, Apr 22, 2005 at 01:19:47AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> So in the long run this issue goes away - we'll just have synchronization 
> tools that won't get any unnecessary pollution. But in the short run I 
> actually check my git archive religiously for being clean, and I do
> 
>   fsck-cache --unreachable $(cat .git/HEAD)
> 
> quite often - not because git has been flaky, but simply beause I'm anal. 
> And getting objects from other branches would mess with that..

(Note that when using git-pasky, you need to do

fsck-cache --unreachable $(cat .git/heads/*)

instead.)

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc3 cpufreq compile error on ppc32

2005-04-21 Thread Benjamin Herrenschmidt

On Thu, 2005-04-21 at 09:26 +0200, Colin Leroy wrote:
> Hi guys,
> 
> One of Ben's patches ("ppc32: Fix cpufreq problems") went in 2.6.12-
> rc3, but it depended on another patch that's still in -mm only: 
> add-suspend-method-to-cpufreq-core.patch
> 
> In addition to this, there's a third patch in -mm that fixes warnings
> and line length to the previous patch, but it doesn't apply cleanly
> anymore. It's named add-suspend-method-to-cpufreq-core-warning-fix.patch

Yup, please, Andrew, get those 2 to Linus.

Ben.

> Here's an updated version. HTH,
> 
> Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
> --- a/drivers/cpufreq/cpufreq.c   2005-04-21 09:14:28.0 +0200
> +++ b/drivers/cpufreq/cpufreq.c   2005-04-21 09:18:11.0 +0200
> @@ -955,7 +955,6 @@
>  {
>   int cpu = sysdev->id;
>   unsigned int ret = 0;
> - unsigned int cur_freq = 0;
>   struct cpufreq_policy *cpu_policy;
>  
>   dprintk("resuming cpu %u\n", cpu);
> @@ -995,21 +994,24 @@
>   cur_freq = cpufreq_driver->get(cpu_policy->cpu);
>  
>   if (!cur_freq || !cpu_policy->cur) {
> - printk(KERN_ERR "cpufreq: resume failed to assert 
> current frequency is what timing core thinks it is.\n");
> + printk(KERN_ERR "cpufreq: resume failed to assert "
> + "current frequency is what timing core "
> + "thinks it is.\n");
>   goto out;
>   }
>  
>   if (unlikely(cur_freq != cpu_policy->cur)) {
>   struct cpufreq_freqs freqs;
>  
> - printk(KERN_WARNING "Warning: CPU frequency is %u, "
> -"cpufreq assumed %u kHz.\n", cur_freq, 
> cpu_policy->cur);
> + printk(KERN_WARNING "Warning: CPU frequency is %u, 
> cpufreq assumed "
> + "%u kHz.\n", cur_freq, 
> cpu_policy->cur);
>  
>   freqs.cpu = cpu;
>   freqs.old = cpu_policy->cur;
>   freqs.new = cur_freq;
>  
> - notifier_call_chain(_transition_notifier_list, 
> CPUFREQ_RESUMECHANGE, );
> + notifier_call_chain(_transition_notifier_list,
> + CPUFREQ_RESUMECHANGE, );
>   adjust_jiffies(CPUFREQ_RESUMECHANGE, );
>  
>   cpu_policy->cur = cur_freq;
> 
> 
-- 
Benjamin Herrenschmidt <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 10/10] tg3: add support for bcm5752 rev a1

On Wed, 13 Apr 2005 19:38:46 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Replace existing ASIC_REV_5752 definition with ASIC_REV_5752_A0,
> and add definition for ASIC_REV_5752_A1. Then, add ASIC_REV_5752_A1
> to check for setting TG3_FLG2_5750_PLUS in tg3_get_invariants.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied, now off to Michael's additions :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] generate hotplug events for cpu online

2005-04-21 Thread Nathan Lynch

On Thu, Apr 21, 2005 at 08:46:56PM +0200, Pavel Machek wrote:
> Hi!
> 
> > We already do kobject_hotplug for cpu offline; this adds a
> > kobject_hotplug call for the online case.  This is being requested by
> > developers of an application which wants to be notified about both
> > kinds of events.
> 
> I'm afraid of bad interactions with swsusp/S3 on smp. We offline cpus there,
> but we probably do not want userland to know...

The kobject_hotplug calls for cpu online and offline are present only
in the code paths where the operation is initiated through the sysfs
interface, so I don't think you have to worry.

Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 9/10] tg3: check TG3_FLG2_5750_PLUS flag to set TG3_FLG2_5705_PLUS flag

On Wed, 13 Apr 2005 19:38:46 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Use check of TG3_FLG2_5750_PLUS in tg3_get_invariants to set
> TG3_FLG2_5705_PLUS flag.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 8/10] tg3: use TG3_FLG2_57{05,50}_PLUS flags in tg3_get_invariants

On Wed, 13 Apr 2005 19:38:45 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Rewrite checks in tg3_get_invariants to use TG3_FLG2_5705_PLUS and
> TG3_FLG2_5750_PLUS flags.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 6/10] tg3: use new TG3_FLG2_5750_PLUS flag

On Wed, 13 Apr 2005 19:38:45 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Replace a number of two-way if statements checking for 5750, and/or
> 5752 to reference the newly-defined TG3_FLG2_5750_PLUS flag instead.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 4/10] tg3: use TG3_FLG2_5705_PLUS instead of multi-way if's

On Wed, 13 Apr 2005 19:38:44 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Replace a number of three-way if statements checking for 5705, 5750,
> and 5752 to reference the equivalent TG3_FLG2_5705_PLUS flag instead.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 5/10] tg3: define TG3_FLG2_5750_PLUS flag

On Wed, 13 Apr 2005 19:38:45 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Define TG3_FLG2_5750_PLUS flag and set it in tg3_get_invariants for
> ASIC_REV_5750 or ASIC_REV_5752.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 3/10] tg3: add bcm5752 entry to pci_ids.h

On Wed, 13 Apr 2005 19:38:44 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Add proper entry for bcm5752 PCI ID to pci_ids.h, and use it in tg3.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> ---
> I did this separately in case patches like this (i.e. new PCI IDs)
> need to come from more "official" sources.

Applied, thanks.  Don't we need a drivers/pci/pci.ids update as
well?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 2/10] tg3: add bcm5752 to tg3_pci_tbl

On Wed, 13 Apr 2005 19:38:44 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Add hard-coded definition of bcm5752 PCI ID to tg3_pci_tbl.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> ---
> Next patch will change entry to use pci_ids.h-based definition.

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2.6.12-rc2 1/10] tg3: add basic bcm5752 support

On Wed, 13 Apr 2005 19:38:43 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:

> Track-down all references to ASIC_REV_5750 and mirror them with
> references to the newly defined ASIC_REV_5752.
> 
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>

You don't actually add the ASIC_REV_5752 definition to tg3.h,
but I took care of that for you when checking this patch in.

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86_64: Bug in new out of line put_user()

2005-04-21 Thread Nicolas Boichat

Hello Alexander,

I have other kind of problems with this patch...

With 2.6.12-rc2 + your patch, when I run OpenOffice (a 32-bit
application), I get this in dmesg :

Unable to handle kernel paging request at 2d9280b0 RIP: 
{__put_user_4+32}
PGD 0 
Oops: 0002 [1] SMP 
CPU 0 
Modules linked in: cpufreq_ondemand sch_sfq sch_htb ipt_CONNMARK
ipt_ipp2p ipt_connmark ipt_mark ipt_tos ipt_length ipt_MARK
iptable_filter iptable_mangle ip_tables powernow_k8 tun nvidia
snd_pcm_oss snd_mixer_oss snd_via82xx snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd cx8800
v4l1_compat v4l2_common cx88xx i2c_algo_bit video_buf ir_common
btcx_risc tveeprom videodev tuner usbhid w83627hf i2c_sensor i2c_isa
i2c_core usb_storage uhci_hcd ehci_hcd usbcore sd_mod scsi_mod
Pid: 11236, comm: soffice.bin Tainted: P  2.6.12-rc2
RIP: 0010:[] {__put_user_4+32}
RSP: :81001d32fea0  EFLAGS: 00010202
RAX: 0003 RBX: 8100255b0f70 RCX: 2d9280b0
RDX:  RSI: 810033534940 RDI: 2d9280b0
RBP:  R08: 81001d32e000 R09: 0002
R10: 81001d32e000 R11: 558740dc R12: 
R13: 810033534940 R14: 0001 R15: 
FS:  2e0ff820() GS:80489840()
knlGS:
CS:  0010 DS: 002b ES: 002b CR0: 8005003b
CR2: 2d9280b0 CR3: 2515 CR4: 06e0
Process soffice.bin (pid: 11236, threadinfo 81001d32e000, task
8100255b0f70)
Stack: 80133414 810019f11138 810033534940
8100255b0f70 
   8100255b0f70  80137c0a
 
    8100255b15a4 
Call Trace:{mm_release+116} {exit_mm
+42} 
   {do_exit+351} {do_group_exit
+252} 
   {ia32_sysret+0} 

It is easily reproducible on my system, I just have to start and exit
OpenOffice 1.1.4.

I got similar messages with 2.6.12-rc3 + your patch (please tell me if
you also want these messages).
I also had one system freeze and one reboot (when I clicked on a link in
Firefox (32-bit app too), I don't know if it is related). But I was
unable to reproduce these crashes, so I'm not sure whether it is caused
by rc3 or by your patch.

Please note that these problems did not occur with 2.6.12-rc2 + these
patches reverted:
 - x86_64-give-out-of-line-get_user-better-calling.patch
 - x86_64-move-put_user-out-of-line.patch
 - x86_64-remove-stale-unused-file.patch

Best regards,

Nicolas

On Thu, 2005-04-21 at 01:10 +0200, Alexander Nyberg wrote: 
> The new out of line put_user() assembly on x86_64 changes %rcx without
> telling GCC about it causing things like:
> 
> http://bugme.osdl.org/show_bug.cgi?id=4515 
> 
> See to it that %rcx is not changed (made it consistent with get_user()).
> 
> 
> Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>
> 
> Index: test/arch/x86_64/lib/getuser.S
> ===
> --- test.orig/arch/x86_64/lib/getuser.S   2005-04-20 23:55:35.0 
> +0200
> +++ test/arch/x86_64/lib/getuser.S2005-04-21 00:54:16.0 +0200
> @@ -78,9 +78,9 @@
>  __get_user_8:
>   GET_THREAD_INFO(%r8)
>   addq $7,%rcx
> - jc bad_get_user
> + jc 40f
>   cmpq threadinfo_addr_limit(%r8),%rcx
> - jae bad_get_user
> + jae 40f
>   subq$7,%rcx
>  4:   movq (%rcx),%rdx
>   xorl %eax,%eax
> Index: test/arch/x86_64/lib/putuser.S
> ===
> --- test.orig/arch/x86_64/lib/putuser.S   2005-04-21 00:50:24.0 
> +0200
> +++ test/arch/x86_64/lib/putuser.S2005-04-21 01:02:15.0 +0200
> @@ -46,36 +46,45 @@
>  __put_user_2:
>   GET_THREAD_INFO(%r8)
>   addq $1,%rcx
> - jc bad_put_user
> + jc 20f
>   cmpq threadinfo_addr_limit(%r8),%rcx
> - jae  bad_put_user
> -2:   movw %dx,-1(%rcx)
> + jae 20f
> +2:   decq %rcx
> + movw %dx,(%rcx)
>   xorl %eax,%eax
>   ret
> +20:  decq %rcx
> + jmp bad_put_user
>  
>   .p2align 4
>  .globl __put_user_4
>  __put_user_4:
>   GET_THREAD_INFO(%r8)
>   addq $3,%rcx
> - jc bad_put_user
> + jc 30f
>   cmpq threadinfo_addr_limit(%r8),%rcx
> - jae bad_put_user
> -3:   movl %edx,-3(%rcx)
> + jae 30f
> +3:   subq $3,%rcx
> + movl %edx,(%rcx)
>   xorl %eax,%eax
>   ret
> +30:  subq $3,%rcx
> + jmp bad_put_user
>  
>   .p2align 4
>  .globl __put_user_8
>  __put_user_8:
>   GET_THREAD_INFO(%r8)
>   addq $7,%rcx
> - jc bad_put_user
> + jc 40f
>   cmpq threadinfo_addr_limit(%r8),%rcx
> - jae bad_put_user
> -4:   movq %rdx,-7(%rcx)
> + jae 40f
> +4:   subq $7,%rcx
> + movq %rdx,(%rcx)
>   xorl %eax,%eax
>   ret
> +40:  subq $7,%rcx
> + jmp bad_put_user
>  
>  bad_put_user:
>   movq $(-EFAULT),%rax
> 
> 
> 

-
To unsubscribe from this list: send the

Re: SATA/ATAPI

2005-04-21 Thread Brian Jackson

Just to check, you do have scsi cdrom support enabled right?

On 4/21/05, Tais M. Hansen <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I know there has been some talking about SATA/ATAPI being experimental and
> might not work at all under kernel-2.6.x.
> 
> One of my linux boxes has a Plextor DVD-RW drive with a SATA interface. The
> kernel sees this drive (ata3) but apparently doesn't tie it to a sdx device.
> The box also have a SATA harddisk, which is working just fine. The relevant
> dmesg output is pasted below.
> 
> Is there anything I can do to help the development of SATA/ATAPI devices?
> 
> libata version 1.10 loaded.
> sata_promise version 1.01
> ACPI: PCI interrupt :00:08.0[A] -> GSI 18 (level, low) -> IRQ 18
> ata1: SATA max UDMA/133 cmd 0xF8804200 ctl 0xF8804238 bmdma 0x0 irq 18
> ata2: SATA max UDMA/133 cmd 0xF8804280 ctl 0xF88042B8 bmdma 0x0 irq 18
> ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003
> 88:407f
> ata1: dev 0 ATA, max UDMA/133, 240121728 sectors:
> ata1: dev 0 configured for UDMA/133
> scsi0 : sata_promise
> ata2: no device found (phy stat )
> scsi1 : sata_promise
>   Vendor: ATA   Model: Maxtor 6Y120M0Rev: YAR5
>   Type:   Direct-Access  ANSI SCSI revision: 05
> sata_via version 1.1
> ACPI: PCI interrupt :00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20
> sata_via(:00:0f.0): routed to hard irq line 4
> ata3: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD400 irq 20
> ata4: SATA max UDMA/133 cmd 0xE000 ctl 0xD802 bmdma 0xD408 irq 20
> ata3: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87:
> 88:0007
> ata3: dev 0 ATAPI, max UDMA/33
> ata3: dev 0 configured for UDMA/33
> scsi2 : sata_via
> ata4: no device found (phy stat )
> scsi3 : sata_via
> SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
> SCSI device sda: drive cache: write back
>  sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> 
> --
> Regards,
> Tais M. Hansen
> OSD
> 
> ___
> "If people had understood how patents would be granted when most of today's
> ideas were invented and had taken out patents, the industry would be at a
> complete standstill today." -Bill Gates (1991)
> 
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] oneshot for inotify.

The Samba guys want dnotify-like oneshot/multishot support.

That is not hard to add, so the following patch adds "oneshot" support
to inotify.  If IN_ONESHOT is set on a watch, the watch is automatically
removed after the first event.  Default behavior remains "multishot."

Best,

Robert Love


Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 fs/inotify.c|2 ++
 include/linux/inotify.h |7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff -urN linux-2.6.12-rc3-inotify/fs/inotify.c linux/fs/inotify.c
--- linux-2.6.12-rc3-inotify/fs/inotify.c   2005-04-21 19:40:44.0 
-0400
+++ linux/fs/inotify.c  2005-04-21 19:37:24.0 -0400
@@ -509,6 +509,8 @@
struct inotify_device *dev = watch->dev;
down(>sem);
inotify_dev_queue_event(dev, watch, mask, cookie, name);
+   if (watch->mask & IN_ONESHOT)
+   remove_watch_no_event(watch, dev);
up(>sem);
}
}
diff -urN linux-2.6.12-rc3-inotify/include/linux/inotify.h 
linux/include/linux/inotify.h
--- linux-2.6.12-rc3-inotify/include/linux/inotify.h2005-04-21 
19:40:44.0 -0400
+++ linux/include/linux/inotify.h   2005-04-21 19:37:25.0 -0400
@@ -49,11 +49,12 @@
 #define IN_DELETE_SELF 0x1000  /* Self was deleted */
 #define IN_UNMOUNT 0x2000  /* Backing fs was unmounted */
 #define IN_Q_OVERFLOW  0x4000  /* Event queued overflowed */
-#define IN_IGNORED 0x8000  /* File was ignored */
 
 /* special flags */
-#define IN_ALL_EVENTS  0x  /* All the events */
-#define IN_CLOSE   (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)
+#define IN_IGNORED 0x8000  /* File was ignored */
+#define IN_ONESHOT 0x8000  /* only send event once */
+#define IN_ALL_EVENTS  (0x & ~IN_ONESHOT) /* All the events */
+#define IN_CLOSE   (IN_CLOSE_WRITE | IN_CLOSE_NOWRITE) /* close */
 
 #define INOTIFY_IOCTL_MAGIC'Q'
 #define INOTIFY_IOCTL_MAXNR2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

2005-04-21 Thread Linus Torvalds

On Fri, 22 Apr 2005, Pavel Machek wrote:
> 
> Is there way to say "git diff -r origin:" but dump it patch-by-patch
> with some usable headers?

In my git version there is a command called "git-export" for exactly this. 
I don't know if Pasky included that in his trees, but if not, you can just 
get my git tree (which should be compatible with Pasky's scripts, but mine 
just has the "core" stuff).

Using "git-export" you can export your whole git tree if you want to, but 
more commonly you'd say

git-export $(cat .git/HEAD) $(cat .git/BASE)

where you'd have saved the previous head that you exported in the BASE
thing (or, if you pull my tree, and want to export your changes back to 
me, you'd initialize BASE to the original HEAD in my tree).

The output format of "git-export" is not the prettiest in the world, but 
I've never actually _used_ that command, I just wrote it as a 
demonstration thing.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Hi!

> > > You should put this into .git/remotes
> > > 
> > > linus 
> > > rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> (git addremote is preferred for that :-)

Nice, so I now have my own -git tree, with two changes in it...

Is there way to say "git diff -r origin:" but dump it patch-by-patch
with some usable headers?

[Looking at git export]
Pavel

Index: Documentation/git.txt
===
--- /dev/null  (tree:9120479b4c721855b378db8907e1259f2e583f2b)
+++ 007d34e2ed3d5fc54cbb4c16880145ade93affef/Documentation/git.txt  
(mode:100644 sha1:939d378ddaac5390c879520c139e66d9649ec4c4)
@@ -0,0 +1,19 @@
+   Kernel hacker's guide to git
+   
+  2005 Pavel Machek <[EMAIL PROTECTED]>
+
+You can get git at http://pasky.or.cz/~pasky/dev/git/ . Compile it,
+and place it somewhere in $PATH. Then you can get kernel by running
+
+git init rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+
+... Run git log to get idea of what happened in tree you are
+tracking. Do git pull linus to pickup latest changes from Linus. You
+can do git diff to see what changes you done in your local tree. git
+cancel will kill any such changes.
+
+You can commit changes by doing git commit... If you want to get diff
+of your changes against mainline, do
+
+git diff -r origin: 
+

-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread Linus Torvalds

On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
> 
> I want to have one "shared objects database" which I keep locally and
> mirror publicly at kernel.org/pub/scm/...

Ahh, ok. That's easy.

Just set up one repository. Then, make SHA1_FILE_DIRECTORY point to that 
repository, and everybody will automatically share all file objects.

HOWEVER. And this is a big however - I don't think you want to do this at 
this point.

Why? Because I'm still using the stupid "get all objects" thing when I
pull. That's not a fundamental design decision, but basically not doing so
requires that the other end be "git aware", and have some server that is
trustworthy that you can tell "get me all objects I need".

In the absense of that kind of git-aware server, anybody pulling from you 
would have to pull _every_ object you have, regardless of whether they 
wanted to use them or not. I don't think that's very nice.

So in the long run this issue goes away - we'll just have synchronization 
tools that won't get any unnecessary pollution. But in the short run I 
actually check my git archive religiously for being clean, and I do

fsck-cache --unreachable $(cat .git/HEAD)

quite often - not because git has been flaky, but simply beause I'm anal. 
And getting objects from other branches would mess with that..

> But now I need a way to indicate to consumers of the public shared object
> data base which HEAD to use.

Yes. You'd just need to document where you put those heads. As you say, 
you can make it be part of an announcement:

> Perhaps I should just say "merge 821376bf15e692941f9235f13a14987009fd0b10
> from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git"?

..but that doesn't actually work very well even for me, because I'd much 
rather automate pulling from you, rather than having to cut-and-paste the 
sha names.

So I think you could just define a head name, and say something like:

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git/HEAD.for-linus

and we're all done. Give andrew a different filename, and you're done. The
above syntax is trivial for me to automate.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fix subarch breakage in amd dual core updates

2005-04-21 Thread James Bottomley

The patch to arch/i386/kernel/cpu/amd.c relies on the variable
cpu_core_id which is defined in i386/kernel/smpboot.c.  This means it is
only present if CONFIG_X86_SMP is defined, not CONFIG_SMP (alternative
SMP harnesses won't have it, which is why it breaks voyager).

Signed-off-by: James Bottomley <[EMAIL PROTECTED]>

arch/i386/kernel/cpu/amd.c: 8d182e875cd72e64b49869386bf090ba23df6793
--- a/arch/i386/kernel/cpu/amd.c
+++ b/arch/i386/kernel/cpu/amd.c
@@ -24,7 +24,7 @@ __asm__(".align 4\nvide: ret");
 
 static void __init init_amd(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_SMP
+#ifdef CONFIG_X86_SMP
int cpu = c == _cpu_data ? 0 : c - cpu_data;
 #endif
u32 l, h;
@@ -198,7 +198,7 @@ static void __init init_amd(struct cpuin
c->x86_num_cores = 1;
}
 
-#ifdef CONFIG_SMP
+#ifdef CONFIG_X86_SMP
/*
 * On a AMD dual core setup the lower bits of the APIC id
 * distingush the cores.  Assumes number of cores is a power


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

from line script for git commits

2005-04-21 Thread James Cloos

I've been using a script grabbed from here for some time to alter
the From: line on mail sent to bk-head-commits and bk-24-commits
to show the author's name and email rather than LKML's address.

Below is my script for doing the same with git commit emails.

-JimC



set-git-from.pl
Description: Perl program

too many LATEST-IS-* on kernel.org?

2005-04-21 Thread Eyal Lebedinsky

In
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
I see
LATEST-IS-2.6.11-rc5   24-Feb-2005 08:580
LATEST-IS-2.6.12-rc1   17-Mar-2005 18:410
LATEST-IS-2.6.12-rc2   04-Apr-2005 09:410
LATEST-IS-2.6.12-rc3   20-Apr-2005 17:210
I thought only the last one is LATEST.
--
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread tony . luck

> It's mainly a clue to bad practice, in my opinion. I personally like the 
> "one repository, one head" approach, and if you want multiple heads you 
> just do multiple repositories (and you can then mix just the object 
> database - set your SHA1_FILE_DIRECTORY environment variable to point to 
> the shared object database, and you're good to go). 

Maybe I just have a terminology problem?

I want to have one "shared objects database" which I keep locally and
mirror publicly at kernel.org/pub/scm/...

I will have several "repositories" locally for various grades of patches,
each of which use SHA1_FILE_DIRECTORY to point to my single repository.
So I never have to worry about getting all the git commands to switch
context ... I just use "cd ../testing", and "cd ../release".

But now I need a way to indicate to consumers of the public shared object
data base which HEAD to use.

Perhaps I should just say "merge 821376bf15e692941f9235f13a14987009fd0b10
from rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git"?

That works for interacting with you, because you only pull from me when
I tell you there is something there to pull.

But Andrew had a cron job or somthing to keep polling every day.  So he
needs to see what the HEAD is.


Does this make sense ... or am I still missing the point?

-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

Dear diary, on Fri, Apr 22, 2005 at 12:29:07AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
> > 
> > I can't quite see how to manage multiple "heads" in git.  I notice that in
> > your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> > perhaps that is a clue.
> 
> It's mainly a clue to bad practice, in my opinion. I personally like the 
> "one repository, one head" approach, and if you want multiple heads you 
> just do multiple repositories (and you can then mix just the object 
> database - set your SHA1_FILE_DIRECTORY environment variable to point to 
> the shared object database, and you're good to go). 

There are two points regarding this:

(i) You need to track heads of remote branches anyway.

(ii) I want an easy way for user to refer to head of another working
tree on the same repository (so that you can do just git merge testing).

This is why the multiple heads are there, and it's actually everything
they _do_. There's nothing more behind it.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

Dear diary, on Thu, Apr 21, 2005 at 11:55:43PM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> I can't quite see how to manage multiple "heads" in git.  I notice that in
> your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> perhaps that is a clue.
> 
> I'd like to have at least two, or perhaps even three "HEADS" active in my
> tree at all times.  One would correspond to my old "release" tree ... pointing
> to changes that I think are ready to go into the Linus tree.  A second would
> be the "testing" tree ... ready for Andrew to pull into "-mm", but not ready
> for the base. The third (which might only exist in my local tree) would be
> for changes that I'm playing around with.

To set up that, go into your "master" working directory, and do:

git fork release ~/release
git fork testing ~/testing

Then in ~/release or ~/testing respectively, you have working trees for
the respective branches.

> I can see how git can easily do this ... but I don't know how to set up my
> public tree so that you and Andrew can pull from the right HEAD.

Currently, git pull will _never_ care about your internal heads
structure in the remote repository. It will just take HEAD at the given
rsync URI, and update the remote branch's head in your repository to
that commit ID.  This actually seems to be one of the very common
pitfalls for people.

The way to work around that is to setup separate rsync URIs for each of
the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
in form

rsync://host/path!branchname

which will allow you to select the particular branch in the given
repository, defaulting to the "master" branch.

Would that work for you?

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86_64: i8259.c trivial iso99 structure initialization

2005-04-21 Thread Alexander Nyberg

Trivial iso99 structure initialization


Index: test/arch/x86_64/kernel/i8259.c
===
--- test.orig/arch/x86_64/kernel/i8259.c2005-04-20 22:29:02.0 
+0200
+++ test/arch/x86_64/kernel/i8259.c 2005-04-22 00:16:22.0 +0200
@@ -158,14 +158,13 @@
 }
 
 static struct hw_interrupt_type i8259A_irq_type = {
-   "XT-PIC",
-   startup_8259A_irq,
-   shutdown_8259A_irq,
-   enable_8259A_irq,
-   disable_8259A_irq,
-   mask_and_ack_8259A,
-   end_8259A_irq,
-   NULL
+   .typename = "XT-PIC",
+   .startup = startup_8259A_irq,
+   .shutdown = shutdown_8259A_irq,
+   .enable = enable_8259A_irq,
+   .disable = disable_8259A_irq,
+   .ack = mask_and_ack_8259A,
+   .end = end_8259A_irq,
 };
 
 /*


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.10-ac10 oops in journal_commit_transaction

2005-04-21 Thread Chris Wright

* Zou, Nanhai ([EMAIL PROTECTED]) wrote:
>   We have seen the same oops on the same point.
> Can you point to me the URL where the patch is? 
> I am not sure which patch should I get.

I believe it's fixed in 2.6.11-ac, and we fixed it in the current stable
2.6.11.7 tree.  The following patch is what went into 2.6.11.7:
---

From: Stephen Tweedie
Subject: Prevent race condition in jbd

This patch from Stephen Tweedie which fixes a race in jbd code (it
demonstrated itself as more or less random NULL dereferences in the
journal code).

Acked-by: Jan Kara <[EMAIL PROTECTED]>
Acked-by: Chris Mason <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

--- linux-2.6-ext3/fs/jbd/transaction.c.=K=.orig
+++ linux-2.6-ext3/fs/jbd/transaction.c
@@ -1775,10 +1775,10 @@ static int journal_unmap_buffer(journal_
JBUFFER_TRACE(jh, "checkpointed: add to BJ_Forget");
ret = __dispose_buffer(jh,
journal->j_running_transaction);
+   journal_put_journal_head(jh);
spin_unlock(>j_list_lock);
jbd_unlock_bh_state(bh);
spin_unlock(>j_state_lock);
-   journal_put_journal_head(jh);
return ret;
} else {
/* There is no currently-running transaction. So the
@@ -1789,10 +1789,10 @@ static int journal_unmap_buffer(journal_
JBUFFER_TRACE(jh, "give to committing trans");
ret = __dispose_buffer(jh,
journal->j_committing_transaction);
+   journal_put_journal_head(jh);
spin_unlock(>j_list_lock);
jbd_unlock_bh_state(bh);
spin_unlock(>j_state_lock);
-   journal_put_journal_head(jh);
return ret;
} else {
/* The orphan record's transaction has
@@ -1813,10 +1813,10 @@ static int journal_unmap_buffer(journal_
journal->j_running_transaction);
jh->b_next_transaction = NULL;
}
+   journal_put_journal_head(jh);
spin_unlock(>j_list_lock);
jbd_unlock_bh_state(bh);
spin_unlock(>j_state_lock);
-   journal_put_journal_head(jh);
return 0;
} else {
/* Good, the buffer belongs to the running transaction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SUGGESTION: Kernel

2005-04-21 Thread James Purser

There is always make gconfig, this is presents a GUI for you. However
keep in mind that compiling your own kernel is never going to be an
idiot proof activity, instead it is something that is going to require a
little bit of knowledge about how the kernel works and how the compile
process works.
-- 
James Purser
http://ksit.dynalias.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: netdev watchdog

2005-04-21 Thread Randy.Dunlap

On Thu, 21 Apr 2005 15:21:30 -0700 Shaun Jackman wrote:

| Upon booting my system, the boot fails and the following message is
| displayed repeatedly:
| 
| NETDEV WATCHDOG: eth0: transmit timed out
| eth0: transmit timed out, tx_status 00 status eb01.
| diagnostics: net 0cfa media 88c0 dma 003a fifo 
| eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
| Flags; bus-master 1, dirty 65(1) current 65(1)
| Transmit list  vs d0c782a0
| 0: @d0c78200 length 802e status 8001002e
| ...
| 
| I also see the same message for eth2. I'd been happily booting this
| 2.6.8.1 kernel for months without trouble. I don't know where this is
| coming from. The drivers for my three NICs are forcedeth, 3c59x, and
| 8139too. I'd be happy to give more information to help.
| 
| Please cc me in your reply. Cheers,
| Shaun

Please see the REPORTING-BUGS file for what info to include
in a bug report.  There's just too much info missing from
this one.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ia64 git pull

2005-04-21 Thread Linus Torvalds

On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote:
> 
> I can't quite see how to manage multiple "heads" in git.  I notice that in
> your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
> perhaps that is a clue.

It's mainly a clue to bad practice, in my opinion. I personally like the 
"one repository, one head" approach, and if you want multiple heads you 
just do multiple repositories (and you can then mix just the object 
database - set your SHA1_FILE_DIRECTORY environment variable to point to 
the shared object database, and you're good to go). 

But yes, if you want to mix heads in the same repo, you can do so, but
it's a bit dangerous to switch between them, since you'll have to blow any
dirty state away, or you end up having checked-out state that is
inconsistent with the particular head you're working on.

Switching a head is pretty easy from a _technical_ perspective: make sure 
your tree is clean (ie fully checked in), and switch the .git/HEAD symlink 
to point to a new head. Then just do

read-tree .git/HEAD
checkout-cache -f -a

and you're done. Assuming most checked-out state matches, it should be 
basically instantaneous.

Oh, and you may want to check that yoy didn't have any files that are now 
stale, using "show-files --others" to show what files are _not_ being 
tracked in the head you just switched to.

I think Pasky has helper functions for doing this, but since I think 
multiple heads is really too confusing for mere mortals like me, I've not 
looked at it.

> I'd like to have at least two, or perhaps even three "HEADS" active in my
> tree at all times.  One would correspond to my old "release" tree ... pointing
> to changes that I think are ready to go into the Linus tree.  A second would
> be the "testing" tree ... ready for Andrew to pull into "-mm", but not ready
> for the base. The third (which might only exist in my local tree) would be
> for changes that I'm playing around with.

I _really_ suggest having separate directories and not play with heads. 

As shown above, git can technically support what you're doing very
efficiently, but the problem is not technology - it's user confusion. It's
just too damn easy to do the wrong thing if you end up using the same
directory for all your heads, and switch between them.

In contrast, having separate directories, all with their own individual 
heads, you are much more likely to know what you're up to by just getting 
the hints from the environment.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lirc and Linux 2.6.11

2005-04-21 Thread Shaun Jackman

I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new kernel. This didn't work either. The error
message lircd gives is...

Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
Apr 21 14:57:52 quince lircd 0.7.1: caught signal

I've also asked the lirc mailing list this question, but has anyone
else run into this trouble with lirc and Linux 2.6.11?

Please cc me in your reply. Thanks,
Shaun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

SUGGESTION: Kernel

2005-04-21 Thread John Mac Donald

i would like to suggest a graphical way to setup and install the
kernel and kernel components, this would make it easier for idiots
like myself to install the kernel with more ease and could solve this
issue of 'bloating'. Making a graphical kernel installer could make it
easier for people to select exactly what they want in their kernel, i 
have no idea if this is even remotely possible because im quite the
noob when it comes to compiling stuff on linux but if it is that could
be a good idea

>_JMN
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

netdev watchdog

2005-04-21 Thread Shaun Jackman

Upon booting my system, the boot fails and the following message is
displayed repeatedly:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status eb01.
diagnostics: net 0cfa media 88c0 dma 003a fifo 
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Flags; bus-master 1, dirty 65(1) current 65(1)
Transmit list  vs d0c782a0
0: @d0c78200 length 802e status 8001002e
...

I also see the same message for eth2. I'd been happily booting this
2.6.8.1 kernel for months without trouble. I don't know where this is
coming from. The drivers for my three NICs are forcedeth, 3c59x, and
8139too. I'd be happy to give more information to help.

Please cc me in your reply. Cheers,
Shaun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH linux-2.6.12-rc2-mm3] serial_cs: Reduce stack usage in serial_event()

2005-04-21 Thread Yum Rayan

This patch reduces the stack usage of the function serial_event() in
serial_cs from 2212 to 228. I used a patched version of gcc 3.4.3 on
i386 with -fno-unit-at-a-time disabled.

This patch is only compile tested. It would be nice to get feedback
from someone that owns the hardware and would like to test it.

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>

 serial_cs.c |  170 ++--
 1 files changed, 110 insertions(+), 60 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c
linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c   2005-04-19
23:20:14.0 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c   2005-04-20
23:22:19.0 -0700
@@ -110,6 +110,13 @@ struct serial_info {
int line[4];
 };
 
+struct serial_cfg_mem {
+   tuple_t tuple;
+   cisparse_t parse;
+   u_char buf[256];
+};
+
+
 static void serial_config(dev_link_t * link);
 static int serial_event(event_t event, int priority,
event_callback_args_t * args);
@@ -388,14 +395,24 @@ static int simple_config(dev_link_t *lin
static int size_table[2] = { 8, 16 };
client_handle_t handle = link->handle;
struct serial_info *info = link->priv;
-   tuple_t tuple;
-   u_char buf[256];
-   cisparse_t parse;
-   cistpl_cftable_entry_t *cf = _entry;
+   struct serial_cfg_mem *cfg_mem;
+   tuple_t *tuple;
+   u_char *buf;
+   cisparse_t *parse;
+   cistpl_cftable_entry_t *cf;
config_info_t config;
int i, j, try;
int s;
 
+   cfg_mem = kmalloc(sizeof(struct serial_cfg_mem), GFP_KERNEL);
+   if (!cfg_mem)
+   return -1;
+   
+   tuple = _mem->tuple;
+   parse = _mem->parse;
+   cf = >cftable_entry;
+   buf = cfg_mem->buf;
+
/* If the card is already configured, look up the port and irq */
i = pcmcia_get_configuration_info(handle, );
if ((i == CS_SUCCESS) && (config.Attributes & CONF_VALID_CLIENT)) {
@@ -408,21 +425,23 @@ static int simple_config(dev_link_t *lin
port = config.BasePort1 + 0x28;
info->slave = 1;
}
-   if (info->slave)
+   if (info->slave) {
+   kfree(cfg_mem);
return setup_serial(handle, info, port, 
config.AssignedIRQ);
+   }
}
link->conf.Vcc = config.Vcc;
 
/* First pass: look for a config entry that looks normal. */
-   tuple.TupleData = (cisdata_t *) buf;
-   tuple.TupleOffset = 0;
-   tuple.TupleDataMax = 255;
-   tuple.Attributes = 0;
-   tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+   tuple->TupleData = (cisdata_t *) buf;
+   tuple->TupleOffset = 0;
+   tuple->TupleDataMax = 255;
+   tuple->Attributes = 0;
+   tuple->DesiredTuple = CISTPL_CFTABLE_ENTRY;
/* Two tries: without IO aliases, then with aliases */
for (s = 0; s < 2; s++) {
for (try = 0; try < 2; try++) {
-   i = first_tuple(handle, , );
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if (i != CS_SUCCESS)
goto next_entry;
@@ -440,14 +459,14 @@ static int simple_config(dev_link_t *lin
goto found_port;
}
 next_entry:
-   i = next_tuple(handle, , );
+   i = next_tuple(handle, tuple, parse);
}
}
}
/* Second pass: try to find an entry that isn't picky about
   its base address, then try to grab any standard serial port
   address, and finally try to get any free port. */
-   i = first_tuple(handle, , );
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if ((i == CS_SUCCESS) && (cf->io.nwin > 0) &&
((cf->io.flags & CISTPL_IO_LINES_MASK) <= 3)) {
@@ -460,7 +479,7 @@ next_entry:
goto found_port;
}
}
-   i = next_tuple(handle, , );
+   i = next_tuple(handle, tuple, parse);
}
 
   found_port:
@@ -468,6 +487,7 @@ next_entry:
printk(KERN_NOTICE
   "serial_cs: no usable port range found, giving up\n");
cs_error(link->handle, RequestIO, i);
+   kfree(cfg_mem);
return -1;
}
 
@@ -481,9 +501,10 @@ next_entry:
i = pcmcia_request_configuration(link->handle, >conf);
if (i != CS_SUCCESS) {

[ANNOUNCE] SCSI repository move from BK to git

2005-04-21 Thread James Bottomley

This is more or less forced by the fact that the 2.6.12-rc3 is now git
based.  So as of now I won't be updating linux-scsi.bkbits.net

Hopefully I've set up broadly similar functionality on www.parisc-
linux.org (with thanks to Dann Frazier and Paul Bame, the parisc-linux
web admins).

To view the currently available SCSI trees, go to

http://www.parisc-linux.org/cgi-bin/gitweb.pl

This is using Kay Sievers' scripts and should give you broadly similar
browsing capabilities to bkbits.

I'm still pushing the diffs and the change logs for all the trees into

http://www.parisc-linux.org/~jejb/scsi_diffs

which has almost the exact same content as the old BK based ones used to
have.  Since git is a very mobile target at the moment, I suspect the
diffs and the changelogs will be of most use to people.


James

P.S. if you have any general git questions, please, I don't want to hear
them.  Ask on the git mailing list:  git@vger.kernel.org (preferably
after having searched the archives http://marc.theaimsgroup.com/?l=git
first).


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.6.10-ac10 oops in journal_commit_transaction

2005-04-21 Thread Zou, Nanhai

Hi Alan,
We have seen the same oops on the same point.
Can you point to me the URL where the patch is? 
I am not sure which patch should I get.

Thanks
Zou Nan hai 

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Cox
> Sent: Monday, March 07, 2005 6:59 AM
> To: Brice Figureau
> Cc: Andrew Morton; Linux Kernel Mailing List
> Subject: Re: 2.6.10-ac10 oops in journal_commit_transaction
> 
> FYI Stephen Tweedie has now posted a patch for 2.6.x that ought to fix
> this one.
> 
> Alan
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

2005-04-21 Thread Yum Rayan

This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.

The patch has only been compile tested. It would be nice to get
feedback if someone that owns the hardware can actually test this
patch.

Acked-by: Jörn Engel <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>

 smc91c92_cs.c |  287 ++
 1 files changed, 189 insertions(+), 98 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c
linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c 2005-04-14
22:15:43.0 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c 2005-04-20
18:12:00.0 -0700
@@ -127,6 +127,12 @@ struct smc_private {
 intrx_ovrn;
 };
 
+struct smc_cfg_mem {
+tuple_t tuple;
+cisparse_t parse;
+u_char buf[255];
+};
+
 /* Special definitions for Megahertz multifunction cards */
 #define MEGAHERTZ_ISR  0x0380
 
@@ -498,14 +504,24 @@ static int mhz_mfc_config(dev_link_t *li
 {
 struct net_device *dev = link->priv;
 struct smc_private *smc = netdev_priv(dev);
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255];
-cistpl_cftable_entry_t *cf = _entry;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+cistpl_cftable_entry_t *cf;
+u_char *buf;
 win_req_t req;
 memreq_t mem;
 int i, k;
 
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+return CS_OUT_OF_RESOURCE;
+
+tuple = _mem->tuple;
+parse = _mem->parse;
+cf = >cftable_entry;
+buf = cfg_mem->buf;
+
 link->conf.Attributes |= CONF_ENABLE_SPKR;
 link->conf.Status = CCSR_AUDIO_ENA;
 link->irq.Attributes =
@@ -514,12 +530,12 @@ static int mhz_mfc_config(dev_link_t *li
 link->io.Attributes2 = IO_DATA_PATH_WIDTH_8;
 link->io.NumPorts2 = 8;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = (cisdata_t *)buf;
-tuple.TupleDataMax = sizeof(buf);
-tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+tuple->Attributes = tuple->TupleOffset = 0;
+tuple->TupleData = (cisdata_t *)buf;
+tuple->TupleDataMax = 255;
+tuple->DesiredTuple = CISTPL_CFTABLE_ENTRY;
 
-i = first_tuple(link->handle, , );
+i = first_tuple(link->handle, tuple, parse);
 /* The Megahertz combo cards have modem-like CIS entries, so
we have to explicitly try a bunch of port combinations. */
 while (i == CS_SUCCESS) {
@@ -532,10 +548,10 @@ static int mhz_mfc_config(dev_link_t *li
if (i == CS_SUCCESS) break;
}
if (i == CS_SUCCESS) break;
-   i = next_tuple(link->handle, , );
+   i = next_tuple(link->handle, tuple, parse);
 }
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 dev->base_addr = link->io.BasePort1;
 
 /* Allocate a memory window, for accessing the ISR */
@@ -544,7 +560,7 @@ static int mhz_mfc_config(dev_link_t *li
 req.AccessSpeed = 0;
 i = pcmcia_request_window(>handle, , >win);
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 smc->base = ioremap(req.Base, req.Size);
 mem.CardOffset = mem.Page = 0;
 if (smc->manfid == MANFID_MOTOROLA)
@@ -556,6 +572,8 @@ static int mhz_mfc_config(dev_link_t *li
&& (smc->cardid == PRODID_MEGAHERTZ_EM3288))
mhz_3288_power(link);
 
+free_cfg_mem:
+kfree(cfg_mem);
 return i;
 }
 
@@ -563,39 +581,61 @@ static int mhz_setup(dev_link_t *link)
 {
 client_handle_t handle = link->handle;
 struct net_device *dev = link->priv;
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255], *station_addr;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+u_char *buf, *station_addr;
+int rc;
+
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+   return -1;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = buf;
-tuple.TupleDataMax = sizeof(buf);
+tuple = _mem->tuple;
+parse = _mem->parse;
+buf = cfg_mem->buf;
+
+tuple->Attributes = tuple->TupleOffset = 0;
+tuple->TupleData = (cisdata_t *)buf;
+tuple->TupleDataMax = 255;
 
 /* Read the station address from the CIS.  It is stored as the last
(fourth) string in the Version 1 Version/ID tuple. */
-tuple.DesiredTuple = CISTPL_VERS_1;
-if (first_tuple(handle, , ) != CS_SUCCESS)
-   return -1;
+tuple->DesiredTuple = CISTPL_VERS_1;
+if (first_tuple(handle, tuple, parse) != CS_SUCCESS) {
+   rc = -1;
+   goto free_cfg_mem;
+}
 /* Ugh -- the EM1144 card has two

Re: ia64 git pull

2005-04-21 Thread tony . luck

Adding linux-kernel to Cc: list, as I'm sure Linus wants to hear from
all maintainers, not just those that hang out on the linux-ia64 list.

>On Thu, 21 Apr 2005, Linus Torvalds wrote:
>Btw, just in case it wasn't obvious anyway: I based pretty much _all_ of
>the git design on three basic goals: performance, distribution and
>integrity checking. Everything else pretty much flows from those three
>things.

>But I really tried to make sure that git ends up not just working as a
>system for me to apply patches, but as a system for me to merge other
>peoples work. And I think technically, git does that merge thing very 
>well, and it's certainly living up to my expectations.

>However, I kind of knew what my expectations _were_ in the first place,
>and as such the thing is very much designed for what I think I needed to
>have to work with you guys. Making it fit the old workflow was obviously a
>big deal, but I don't know how people really worked on the "other end",
>so...

>In other words, what this digression is leading up to is just me saying
>that if you have feedback on how this whole git thing is working for
>_you_, please don't feel shy. I realize that it's a bit raw and rough
>right now, and people are working on making for better interfaces, but if
>you have some particular worry or issue, don't feel like git was forced
>upon you as a fait accomplí, but complain and tell me what your biggest
>problems are.

>I may not be able to do a lot about them (the unmentioned fourth basic
>goal was obviously: simple enough that I could actually implement the dang
>thing), but still..

>So if there's some feature (or _lack_ of one) that really bugs you, speak 
>up.

I can't quite see how to manage multiple "heads" in git.  I notice that in
your tree on kernel.org that .git/HEAD is a symlink to heads/master ...
perhaps that is a clue.

I'd like to have at least two, or perhaps even three "HEADS" active in my
tree at all times.  One would correspond to my old "release" tree ... pointing
to changes that I think are ready to go into the Linus tree.  A second would
be the "testing" tree ... ready for Andrew to pull into "-mm", but not ready
for the base. The third (which might only exist in my local tree) would be
for changes that I'm playing around with.

I can see how git can easily do this ... but I don't know how to set up my
public tree so that you and Andrew can pull from the right HEAD.

-Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Dear diary, on Thu, Apr 21, 2005 at 11:38:11PM CEST, I got a letter
where Pavel Machek <[EMAIL PROTECTED]> told me that...
> Hi!
> 
> It seems that someone should write "Kernel hacker's guide to
> git"... Documentation/git.txt seems like good place. I guess I'll do
> it.

I've also started writing some tutorial-like guide to Cogito on my
notebook, but I have time for that only during lectures. :^)

> > I'm not yet sure if we should have some Cogito interface for doing this
> > and what its semantics should be.
> 
> What is Cogito, BTW?

New name for git-pasky. Everyone will surely rejoice as the usage will
change significantly. But better let's clean it up now.

(For more details, check git@ archives for git-pasky-0.6 announcement.)

> > > I see quite a lot of problems with fsck-tree. Is that normal?
> > > (I ran out of disk space few times during different operations...)
> > 
> > Actually, in case your tree is older than about two days, I hope you did
> > the convert-cache magic or fetched a fresh tree?
> 
> No, I did not anything like that. I guess it is rm -rf time, then...

That's the root of all your problems then.

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Hi!

It seems that someone should write "Kernel hacker's guide to
git"... Documentation/git.txt seems like good place. I guess I'll do
it.

> > just plain vanilla" without rm -rf?
> 
> git cancel will give you "plain last commit". If you need plain vanilla,
> the "hard way" now is to just do
> 
>   commit-id >.git/HEAD
> 
> but your current HEAD will be lost forever. Or do
> 
>   git fork vanilla ~/vanilla linus
> 
> and you will have the vanilla tree tracking linus in ~/vanilla.

Ok, thanks.

> I'm not yet sure if we should have some Cogito interface for doing this
> and what its semantics should be.

What is Cogito, BTW?

> > I see quite a lot of problems with fsck-tree. Is that normal?
> > (I ran out of disk space few times during different operations...)
> 
> Actually, in case your tree is older than about two days, I hope you did
> the convert-cache magic or fetched a fresh tree?

No, I did not anything like that. I guess it is rm -rf time, then...

Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH] i386: fix hpet for systems that don't support legacy replacement (v. A0)

2005-04-21 Thread john stultz

All,
Currently the i386 HPET code assumes the entire HPET implementation
from the spec is present. This breaks on boxes that do not implement the
optional legacy timer replacement functionality portion of the spec.

This patch, which is very similar to my x86-64 patch for the same issue,
fixes the problem allowing i386 systems that cannot use the HPET for the
timer interrupt and RTC to still use the HPET as a time source. I've
tested this patch on a system systems without HPET, with HPET but
without legacy timer replacement, as well as HPET with legacy timer
replacement.

Comments and feedback would be appreciated.

thanks
-john

Changelog:
A0: First sent to lkml

diff -Nru a/arch/i386/kernel/time_hpet.c b/arch/i386/kernel/time_hpet.c
--- a/arch/i386/kernel/time_hpet.c  2005-04-21 13:55:07 -07:00
+++ b/arch/i386/kernel/time_hpet.c  2005-04-21 13:55:07 -07:00
@@ -26,6 +26,7 @@
 static unsigned long hpet_period;  /* fsecs / HPET clock */
 unsigned long hpet_tick;   /* hpet clks count per tick */
 unsigned long hpet_address;/* hpet memory map physical address */
+int hpet_use_timer;
 
 static int use_hpet;   /* can be used for runtime check of hpet */
 static int boot_hpet_disable;  /* boottime override for HPET timer */
@@ -73,27 +74,30 @@
hpet_writel(0, HPET_COUNTER);
hpet_writel(0, HPET_COUNTER + 4);
 
-   /*
-* Set up timer 0, as periodic with first interrupt to happen at
-* hpet_tick, and period also hpet_tick.
-*/
-   cfg = hpet_readl(HPET_T0_CFG);
-   cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
-  HPET_TN_SETVAL | HPET_TN_32BIT;
-   hpet_writel(cfg, HPET_T0_CFG);
-
-   /*
-* The first write after writing TN_SETVAL to the config register sets
-* the counter value, the second write sets the threshold.
-*/
-   hpet_writel(tick, HPET_T0_CMP);
-   hpet_writel(tick, HPET_T0_CMP);
+   if (hpet_use_timer) {
+   /*
+* Set up timer 0, as periodic with first interrupt to happen at
+* hpet_tick, and period also hpet_tick.
+*/
+   cfg = hpet_readl(HPET_T0_CFG);
+   cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
+  HPET_TN_SETVAL | HPET_TN_32BIT;
+   hpet_writel(cfg, HPET_T0_CFG);
 
+   /*
+* The first write after writing TN_SETVAL to the config 
register sets
+* the counter value, the second write sets the threshold.
+*/
+   hpet_writel(tick, HPET_T0_CMP);
+   hpet_writel(tick, HPET_T0_CMP);
+   }
/*
 * Go!
 */
cfg = hpet_readl(HPET_CFG);
-   cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+   if (hpet_use_timer)
+   cfg |= HPET_CFG_LEGACY;
+   cfg |= HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
 
return 0;
@@ -128,12 +132,11 @@
 * However, we can do with one timer otherwise using the
 * the single HPET timer for system time.
 */
-   if (
 #ifdef CONFIG_HPET_EMULATE_RTC
-   !(id & HPET_ID_NUMBER) ||
-#endif
-   !(id & HPET_ID_LEGSUP))
+   if (!(id & HPET_ID_NUMBER))
return -1;
+#endif
+
 
hpet_period = hpet_readl(HPET_PERIOD);
if ((hpet_period < HPET_MIN_PERIOD) || (hpet_period > HPET_MAX_PERIOD))
@@ -152,6 +155,8 @@
if (hpet_tick_rem > (hpet_period >> 1))
hpet_tick++; /* rounding the result */
 
+   hpet_use_timer = id & HPET_ID_LEGSUP;
+
if (hpet_timer_stop_set_go(hpet_tick))
return -1;
 
@@ -202,7 +207,8 @@
 #endif
 
 #ifdef CONFIG_X86_LOCAL_APIC
-   wait_timer_tick = wait_hpet_tick;
+   if (hpet_use_timer)
+   wait_timer_tick = wait_hpet_tick;
 #endif
return 0;
 }
diff -Nru a/arch/i386/kernel/timers/timer_hpet.c 
b/arch/i386/kernel/timers/timer_hpet.c
--- a/arch/i386/kernel/timers/timer_hpet.c  2005-04-21 13:55:07 -07:00
+++ b/arch/i386/kernel/timers/timer_hpet.c  2005-04-21 13:55:07 -07:00
@@ -79,7 +79,7 @@
 
eax = hpet_readl(HPET_COUNTER);
eax -= hpet_last;   /* hpet delta */
-
+   eax = min(hpet_tick, eax);
/*
  * Time offset = (hpet delta) * ( usecs per HPET clock )
 * = (hpet delta) * ( usecs per tick / HPET clocks per tick)
@@ -105,9 +105,12 @@
last_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
rdtsc(last_tsc_low, last_tsc_high);
 
-   offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
-   if (unlikely(((offset - hpet_last) > hpet_tick) && (hpet_last != 0))) {
-   int lost_ticks = (offset - hpet_last) / hpet_tick;
+   if (hpet_use_timer)
+   offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+   else
+   offset = hpet_readl(HPET_COUNTER);
+   if (unlikely(((offset - hpet_last) >=

Re: Linux 2.6.12-rc3: various swsusp problems

2005-04-21 Thread Andreas Steinmetz

Pavel Machek wrote:
> Hi!
> Are they new or were they in -rc2, too?

Some further backtracking:

The nic problem is already present in 2.6.12-rc1.
The pcmcia hang problem is not present in 2.6.12-rc1.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration

2005-04-21 Thread Domen Puncer

On 21/04/05 09:36 -0400, Ed L Cashin wrote:
> "Bodo Eggert <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> writes:
> 
> > Ed L Cashin <[EMAIL PROTECTED]> wrote:
> >
...
> >> +  /sys/module/aoe/parameters/aoe_iflist instead of
> > ^^^
> >
> > Why does the module name need to be part of the attribute?
> > That's redundant. That's redundant.
> 
> Yes.  That's true.  Redundancy isn't always bad, though, and using the
> "aoe_" prefix lets the kernel parameter for the built-in aoe driver be
> the same as the parameter for the modular driver.

The __setup() stuff is redundancy too, as module parameters already
work as boot parameters (ie. aoe.iflist).


Domen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/ieee1394/ieee1394_transactions.c: possible cleanups

2005-04-21 Thread Jody McIntyre

On Tue, Apr 19, 2005 at 02:45:23AM +0200, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - #if 0 the following unused global functions:
>   - hpsb_lock
>   - hpsb_send_gasp
> - ieee1394_transactions.h: remove the stale hpsb_lock64 prototype

I also removed the EXPORT_SYMBOL of hpsb_lock, since we're not (yet?)
accepting your earlier patch.

Applied to our SVN and queued for 2.6.13.  Thanks.

Jody

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/ieee1394/ieee1394_transactions.c |3 +++
>  drivers/ieee1394/ieee1394_transactions.h |7 ---
>  2 files changed, 3 insertions(+), 7 deletions(-)
> 
> --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.h.old
> 2005-04-19 00:24:13.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.h
> 2005-04-19 00:25:00.0 +0200
> @@ -53,12 +53,5 @@
> u64 addr, quadlet_t *buffer, size_t length);
>  int hpsb_write(struct hpsb_host *host, nodeid_t node, unsigned int 
> generation,
>  u64 addr, quadlet_t *buffer, size_t length);
> -int hpsb_lock(struct hpsb_host *host, nodeid_t node, unsigned int generation,
> -   u64 addr, int extcode, quadlet_t *data, quadlet_t arg);
> -int hpsb_lock64(struct hpsb_host *host, nodeid_t node, unsigned int 
> generation,
> - u64 addr, int extcode, octlet_t *data, octlet_t arg);
> -int hpsb_send_gasp(struct hpsb_host *host, int channel, unsigned int 
> generation,
> -   quadlet_t *buffer, size_t length, u32 specifier_id,
> -   unsigned int version);
>  
>  #endif /* _IEEE1394_TRANSACTIONS_H */
> --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.c.old
> 2005-04-19 00:24:31.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.c
> 2005-04-19 00:24:51.0 +0200
> @@ -535,6 +535,7 @@
>  return retval;
>  }
>  
> +#if 0
>  
>  int hpsb_lock(struct hpsb_host *host, nodeid_t node, unsigned int generation,
> u64 addr, int extcode, quadlet_t *data, quadlet_t arg)
> @@ -599,3 +600,5 @@
>  
>   return retval;
>  }
> +
> +#endif  /*  0  */
> 
> 
> 
> ---
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> ___
> mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC: 2.6 patch] drivers/ieee1394/pcilynx.c: remove dead options

2005-04-21 Thread Jody McIntyre

On Sun, Apr 17, 2005 at 10:14:24PM +0200, Adrian Bunk wrote:
> The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and 
> CONFIG_IEEE1394_PCILYNX_PORTS are not available for some time.
> 
> Is this patch for removing them and the code behind them correct, or is 
> a future usage planned?

I don't see a use for them, and I'm probably the only person who cares
about pcilynx :)  Applied to our SVN, will send in for 2.6.13.

Thanks,
Jody

> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/ieee1394/Kconfig   |5 
>  drivers/ieee1394/pcilynx.c |  391 -
>  drivers/ieee1394/pcilynx.h |   49 
>  3 files changed, 2 insertions(+), 443 deletions(-)
> 
> --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/Kconfig.old2005-04-17 
> 21:01:11.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/Kconfig2005-04-17 
> 21:01:23.0 +0200
> @@ -84,11 +84,6 @@
> To compile this driver as a module, say M here: the
> module will be called pcilynx.
>  
> -# Non-maintained pcilynx options
> -# if [ "$CONFIG_IEEE1394_PCILYNX" != "n" ]; then
> -# bool 'Use PCILynx local RAM' CONFIG_IEEE1394_PCILYNX_LOCALRAM
> -# bool 'Support for non-IEEE1394 local ports' 
> CONFIG_IEEE1394_PCILYNX_PORTS
> -# fi
>  config IEEE1394_OHCI1394
>   tristate "OHCI-1394 support"
>   depends on PCI && IEEE1394
> --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.h.old  2005-04-17 
> 21:01:31.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.h  2005-04-17 
> 21:02:21.0 +0200
> @@ -55,16 +55,6 @@
>  void __iomem *aux_port;
>   quadlet_t bus_info_block[5];
>  
> -#ifdef CONFIG_IEEE1394_PCILYNX_PORTS
> -atomic_t aux_intr_seen;
> -wait_queue_head_t aux_intr_wait;
> -
> -void *mem_dma_buffer;
> -dma_addr_t mem_dma_buffer_dma;
> -struct semaphore mem_dma_mutex;
> -wait_queue_head_t mem_dma_intr_wait;
> -#endif
> -
>  /*
>   * use local RAM of LOCALRAM_SIZE bytes for PCLs, which allows for
>   * LOCALRAM_SIZE * 8 PCLs (each sized 128 bytes);
> @@ -72,11 +62,9 @@
>   */
>  u8 pcl_bmap[LOCALRAM_SIZE / 1024];
>  
> -#ifndef CONFIG_IEEE1394_PCILYNX_LOCALRAM
>   /* point to PCLs memory area if needed */
>   void *pcl_mem;
>  dma_addr_t pcl_mem_dma;
> -#endif
>  
>  /* PCLs for local mem / aux transfers */
>  pcl_t dmem_pcl;
> @@ -378,39 +366,6 @@
>  #define pcloffs(MEMBER) (offsetof(struct ti_pcl, MEMBER))
>  
>  
> -#ifdef CONFIG_IEEE1394_PCILYNX_LOCALRAM
> -
> -static inline void put_pcl(const struct ti_lynx *lynx, pcl_t pclid,
> -   const struct ti_pcl *pcl)
> -{
> -int i;
> -u32 *in = (u32 *)pcl;
> -u32 *out = (u32 *)(lynx->local_ram + pclid * sizeof(struct ti_pcl));
> -
> -for (i = 0; i < 32; i++, out++, in++) {
> -writel(*in, out);
> -}
> -}
> -
> -static inline void get_pcl(const struct ti_lynx *lynx, pcl_t pclid,
> -   struct ti_pcl *pcl)
> -{
> -int i;
> -u32 *out = (u32 *)pcl;
> -u32 *in = (u32 *)(lynx->local_ram + pclid * sizeof(struct ti_pcl));
> -
> -for (i = 0; i < 32; i++, out++, in++) {
> -*out = readl(in);
> -}
> -}
> -
> -static inline u32 pcl_bus(const struct ti_lynx *lynx, pcl_t pclid)
> -{
> -return pci_resource_start(lynx->dev, 1) + pclid * sizeof(struct 
> ti_pcl);
> -}
> -
> -#else /* CONFIG_IEEE1394_PCILYNX_LOCALRAM */
> -
>  static inline void put_pcl(const struct ti_lynx *lynx, pcl_t pclid,
> const struct ti_pcl *pcl)
>  {
> @@ -431,10 +386,8 @@
>  return lynx->pcl_mem_dma + pclid * sizeof(struct ti_pcl);
>  }
>  
> -#endif /* CONFIG_IEEE1394_PCILYNX_LOCALRAM */
> -
>  
> -#if defined (CONFIG_IEEE1394_PCILYNX_LOCALRAM) || defined (__BIG_ENDIAN)
> +#if defined (__BIG_ENDIAN)
>  typedef struct ti_pcl pcltmp_t;
>  
>  static inline struct ti_pcl *edit_pcl(const struct ti_lynx *lynx, pcl_t 
> pclid,
> --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.c.old  2005-04-17 
> 21:02:29.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.c  2005-04-17 
> 21:05:02.0 +0200
> @@ -834,327 +834,6 @@
>   * IEEE-1394 functionality section END *
>   ***/
>  
> -#ifdef CONFIG_IEEE1394_PCILYNX_PORTS
> -/* VFS functions for local bus / aux device access.  Access to those
> - * is implemented as a character device instead of block devices
> - * because buffers are not wanted for this.  Therefore llseek (from
> - * VFS) can be used for these char devices with obvious effects.
> - */
> -static int mem_open(struct inode*, struct file*);
> -static int mem_release(struct inode*, struct file*);
> -static unsigned int aux_poll(struct file*, struct poll_table_struct*);
> -static loff_t mem_llseek(struct file*,

Re: [PATCH] ieee1394: remove NULL checks prior to kfree in ieee1394, kfree handles null pointers fine.

2005-04-21 Thread Jody McIntyre

On Sat, Apr 16, 2005 at 05:55:19PM +0200, Jesper Juhl wrote:
> This patch removes redundant NULL pointer checks before kfree() in all of 
> drivers/ieee1394/

Thanks, applied to our SVN and queued for 2.6.13.

Jody

> 
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
> 
>  drivers/ieee1394/nodemgr.c   |3 +--
>  drivers/ieee1394/ohci1394.c  |2 +-
>  drivers/ieee1394/video1394.c |   29 -
>  3 files changed, 10 insertions(+), 24 deletions(-)
> 
> 
> diff -upr linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/nodemgr.c 
> linux-2.6.12-rc2-mm3/drivers/ieee1394/nodemgr.c
> --- linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/nodemgr.c  2005-04-11 
> 21:20:41.0 +0200
> +++ linux-2.6.12-rc2-mm3/drivers/ieee1394/nodemgr.c   2005-04-16 
> 17:44:23.0 +0200
> @@ -1006,8 +1006,7 @@ static struct unit_directory *nodemgr_pr
>   return ud;
>  
>  unit_directory_error:
> - if (ud != NULL)
> - kfree(ud);
> + kfree(ud);
>   return NULL;
>  }
>  
> diff -upr linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/ohci1394.c 
> linux-2.6.12-rc2-mm3/drivers/ieee1394/ohci1394.c
> --- linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/ohci1394.c 2005-04-05 
> 21:21:24.0 +0200
> +++ linux-2.6.12-rc2-mm3/drivers/ieee1394/ohci1394.c  2005-04-16 
> 17:44:48.0 +0200
> @@ -2893,7 +2893,7 @@ static void free_dma_rcv_ctx(struct dma_
>   kfree(d->prg_cpu);
>   kfree(d->prg_bus);
>   }
> - if (d->spb) kfree(d->spb);
> + kfree(d->spb);
>  
>   /* Mark this context as freed. */
>   d->ohci = NULL;
> diff -upr linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/video1394.c 
> linux-2.6.12-rc2-mm3/drivers/ieee1394/video1394.c
> --- linux-2.6.12-rc2-mm3-orig/drivers/ieee1394/video1394.c2005-04-11 
> 21:20:41.0 +0200
> +++ linux-2.6.12-rc2-mm3/drivers/ieee1394/video1394.c 2005-04-16 
> 17:47:03.0 +0200
> @@ -180,23 +180,13 @@ static int free_dma_iso_ctx(struct dma_i
>   kfree(d->prg_reg);
>   }
>  
> - if (d->ir_prg)
> - kfree(d->ir_prg);
> -
> - if (d->it_prg)
> - kfree(d->it_prg);
> -
> - if (d->buffer_status)
> - kfree(d->buffer_status);
> - if (d->buffer_time)
> - kfree(d->buffer_time);
> - if (d->last_used_cmd)
> - kfree(d->last_used_cmd);
> - if (d->next_buffer)
> - kfree(d->next_buffer);
> -
> + kfree(d->ir_prg);
> + kfree(d->it_prg);
> + kfree(d->buffer_status);
> + kfree(d->buffer_time);
> + kfree(d->last_used_cmd);
> + kfree(d->next_buffer);
>   list_del(>link);
> -
>   kfree(d);
>  
>   return 0;
> @@ -1060,8 +1050,7 @@ static int __video1394_ioctl(struct file
>   PRINT(KERN_ERR, ohci->host->id,
> "Buffer %d is already used",v.buffer);
>   spin_unlock_irqrestore(>lock,flags);
> - if (psizes)
> - kfree(psizes);
> + kfree(psizes);
>   return -EBUSY;
>   }
>  
> @@ -1116,9 +1105,7 @@ static int __video1394_ioctl(struct file
>   }
>   }
>  
> - if (psizes)
> - kfree(psizes);
> -
> + kfree(psizes);
>   return 0;
>  
>   }
> 
> 
> 
> -- 
> Jesper Juhl
> 
> PS. Please CC: me on replies as I'm not subscribed to the linux1394-devel 
> list.
> 
> 
> 
> 
> ---
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595_id=14396=click
> ___
> mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc3 compile failure in tgafb.c

2005-04-21 Thread Adrian Bunk

On Thu, Apr 21, 2005 at 09:50:34PM +0300, Tomi Lapinlampi wrote:
> 
> Hi,
> 
> 2.6.12-rc3 compile fails in drivers/video/tgafb.c
> 
> The system is an Alphastation 600 5/266, system variant Alcor,
> running Debian Sarge, gcc version 3.3.5 (Debian 1:3.3.5-8)
> 
> Btw, the tgafb hasn't really worked on this hardware since 2.6.8.1.
> I'll be able to run more tests after this one compiles :)
> 
> Regards,
> 
> Tomi
> 
> % make
>   CHK include/linux/version.h
> make[1]: `arch/alpha/kernel/asm-offsets.s' is up to date.
>   CHK include/asm-alpha/asm_offsets.h
>   CHK include/linux/compile.h
>   CHK usr/initramfs_list
>   CC  drivers/video/tgafb.o
> drivers/video/tgafb.c:85: error: `tgafb_pci_unregister' undeclared here (not 
> in a function)
> drivers/video/tgafb.c:85: error: initializer element is not constant
> drivers/video/tgafb.c:85: error: (near initialization for 
> `tgafb_driver.remove')
> make[2]: *** [drivers/video/tgafb.o] Error 1
> make[1]: *** [drivers/video] Error 2
> make: *** [drivers] Error 2
>...

The untested patch below should fix this compile error.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.12-rc2-mm3-full/drivers/video/tgafb.c.old 2005-04-21 
22:38:42.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/tgafb.c 2005-04-21 
22:39:36.0 +0200
@@ -45,9 +45,7 @@
 static void tgafb_copyarea(struct fb_info *, const struct fb_copyarea *);
 
 static int tgafb_pci_register(struct pci_dev *, const struct pci_device_id *);
-#ifdef MODULE
 static void tgafb_pci_unregister(struct pci_dev *);
-#endif
 
 static const char *mode_option = "[EMAIL PROTECTED]";
 
@@ -1484,7 +1482,6 @@
return ret;
 }
 
-#ifdef MODULE
 static void __exit
 tgafb_pci_unregister(struct pci_dev *pdev)
 {
@@ -1500,6 +1497,7 @@
kfree(info);
 }
 
+#ifdef MODULE
 static void __exit
 tgafb_exit(void)
 {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11] [corrected] Documentation: remove super-{nr, max} to reflect fs/super.c

The patch updates the documentation for /proc. super-nr and super-max have
been dropped from the kernel since 2.4.9 due to minor numbering issues.
This change was not documented in the documentation.
The original patch submitted just a while ago had the files
reversed. Sorry about that.

--- linux-2.6.11/Documentation/filesystems/proc.txt.orig2005-04-21 
16:38:33.900779693 -0400
+++ linux-2.6.11/Documentation/filesystems/proc.txt 2005-04-21 
16:38:45.805174536 -0400
@@ -909,16 +909,6 @@ nr_free_inodes
 Represents the  number of free inodes. Ie. The number of inuse inodes is
 (nr_inodes - nr_free_inodes).
 
-super-nr and super-max
---
-
-Again, super  block structures are allocated by the kernel, but not freed. The
-file super-max  contains  the  maximum  number  of super block handlers, where
-super-nr shows the number of currently allocated ones.
-
-Every mounted file system needs a super block, so if you plan to mount lots of
-file systems, you may want to increase these numbers.
-
 aio-nr and aio-max-nr
 -

Signed-off-by: Cosmin Nicolaescu <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Arjan van de Ven

On Thu, 2005-04-21 at 13:25 -0700, Chris Wright wrote:
> * Timur Tabi ([EMAIL PROTECTED]) wrote:
> > It works with every kernel I've tried.  I'm sure there are plenty of kernel 
> > configuration options that will break our driver.  But as long as all the 
> > distros our customers use work, as well as reasonably-configured custom 
> > kernels, we're happy.
> > 
> 
> Hey, if you're happy (and, as you said, you don't intend to merge that
> bit), I'm happy ;-)


yeah... drivers giving unprivileged processes more privs belong on
bugtraq though, not in the core kernel :)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Chris Wright

* Timur Tabi ([EMAIL PROTECTED]) wrote:
> It works with every kernel I've tried.  I'm sure there are plenty of kernel 
> configuration options that will break our driver.  But as long as all the 
> distros our customers use work, as well as reasonably-configured custom 
> kernels, we're happy.
> 

Hey, if you're happy (and, as you said, you don't intend to merge that
bit), I'm happy ;-)

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Timur Tabi

Chris Wright wrote:
FYI, that will not work on all 2.6 kernels.  Specifically anything that's
not using capabilities.
It works with every kernel I've tried.  I'm sure there are plenty of kernel configuration 
options that will break our driver.  But as long as all the distros our customers use 
work, as well as reasonably-configured custom kernels, we're happy.

--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
 -- Ed Smylie, NASA engineer for Apollo 13
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Chris Wright

* Timur Tabi ([EMAIL PROTECTED]) wrote:
> Andy Isaacson wrote:
> >Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
> >pages?  Or are you doing something more nasty?
> 
> A little more nasty.  I raise RLIMIT_MEMLOCK in the driver to "unlimited" 
> and also set cap_raise(IPC_LOCK).  I do this because I need to support all 
> 2.4 and 2.6 kernel versions with the same driver, but only 2.6.10 and later 
> have any support for non-root mlock().

FYI, that will not work on all 2.6 kernels.  Specifically anything that's
not using capabilities.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Timur Tabi

Andy Isaacson wrote:
I'm familiar with MPI 1.0 and 2.0, but I haven't been following the
development of modern messaging APIs, so I might not make sense here...
Assuming that the app calls into the library on a fairly regular basis,
Not really. The whole point is to have the adapter DMA the data directly from memory to
the network. That's why it's called RDMA - remote DMA.

Therefore, cluster admins are going to do their
darndest to avoid this behavior, so we might as well just kill the job
and make it explicit.
Yes, and if it turns out that the same MPI application dies on Linux but not on Solaris
because Linux doesn't really care if the memory stays pinned, then we're going to see a
lot of MPI customers transitioning away from Linux.

*You* need to come up with a solution that looks good to *the community*
if you want it merged.
True, but I'm not going to waste my time adding this support if the consensus I get from
the kernel developers that they don't want Linux to behave this way.

Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
pages? Or are you doing something more nasty?
A little more nasty. I raise RLIMIT_MEMLOCK in the driver to "unlimited" and also set
cap_raise(IPC_LOCK). I do this because I need to support all 2.4 and 2.6 kernel versions
with the same driver, but only 2.6.10 and later have any support for non-root mlock().

If and when our driver is submitted to the official kernel, that nastiness will be removed
of course.

--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

a few dbench datapoints across various filesystems

2005-04-21 Thread Steve French

I ran some quick tests with dbench to see the effects of various
performance improvements, and found the results interesting. Although
dbench is too write oriented, and not particularly favorable to a few
filesystems (who are otherwise good performers), dbench can still can be
useful.

System was a Pentium 4 2.40 GHz, uni, IDE drive, 1GB RAM
Kernel was mainline: 2.6.12-rc2. dbench version 3.03 from samba.org 


Unfortunately the two target partitions were not the exact same size
(the small partition size may skew some ext3 results somewhat higher,
but it saved time to avoid reformatting my development machine). 
partition sizes were 16.5 GB vs JFS 2 GB EXT3

Network filesystems tests (nfs v3, cifs, smbfs) were mounted over
localhost to minimize the effects of network adapter differences.
The cifs code was using the current version of cifs.ko (version 1.33)
newer than what is in mainline.

JFS Throughput 52.6572 MB/sec 20 procs
ext3 Throughput 179.726 MB/sec 20 procs
ext3 (2nd run) Throughput 180.409 MB/sec 20 procs
cifs mounted to samba/JFS 9.67401 Throughput MB/sec 20 procs
cifs mounted to samba/ext3 Throughput 12.2919 MB/sec 20 procs
nfs mounted to JFS Throughput 16.3588 MB/sec 20 procs
nfs mounted to ext3 Throughput 13.5945 MB/sec 20 procs
nfs mounted to ext3 (2nd run) Throughput 12.4307 MB/sec 20 procs

Then using newer JFS code with the faster JFS code from current mm tree
for the following five:
JFS Throughput 58.3836 MB/sec 20 procs
nfs mount to jfs Throughput 16.562 MB/sec 20 procs
smbfs mount to Samba/jfs Throughput 16.4742 MB/sec 20 procs
cifs larger mempool (40 buffers) (to Samba/jfs) 
Throughput 12.8196 MB/sec 20 procs
cifs larger mempool (40 buffers), mount with directio mount option 
(to Samba/JFS)
Throughput 14.1643 MB/sec 20 procs

The cifs numbers are much improved, and should be pretty easy to get to
another 20 or 30% faster, which I will look at doing once we finishing
testing cifs version 1.33

Interesting that JFS was slower than ext3 for the local test, but faster
than ext3 when mounting via NFS to the same system, same filesystem. 
The JFS performance guys are apparently close to improving the local
dbench numbers since dbench shows a performance issue with writing
synchr. to the journal where other fs are able to do it faster (JFS does
well apparently on most of the other benchmarks, and my informal tests
showed that JFS was faster on various simple perf tests as well).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3: various swsusp problems

2005-04-21 Thread Andreas Steinmetz

Pavel Machek wrote:
> Hi!
> 
> 
>>there's some problems with swsusp in 2.6.12-rc3 (x86_64):
> 
> 
> Are they new or were they in -rc2, too?
> 

Fixed the rc2/rc3 IDE Oops myself today that prevented me to test rc2
earlier. It seems the IDE maintainer is currently not very responsive
and I didn't have sufficient spare time to look into this before today :-(

Yes, all problems are already in rc2.

> 
>>1. Is it necessary to print the following message during regular boot?
>>   swsusp: Suspend partition has wrong signature?
>>   It is a bit annoying and I believe it will confuse some swsusp
>>   users.
> 
> 
> Hmm, feel free to provide a patch. (I need something to try git on :-).

I'll have a look over the weekend.

> 
> 
>>2. PCMCIA related hangs during swsusp.
>>   swsusp hangs after freeing memory when either cardmgr is running
>>   or pcmcia cards are *physically* inserted. It is insufficient
>>   to do a 'cardctl eject' the cards must be removed, too, for
>>   swsusp not to hang. I do suspect some problem with the
>>   'pccardd' kernel threads.
> 
> 
> Did it work with any older kernel? Which driver is it? yenta?

2.6.11.2 works ok and, yes, its yenta. Some excerpt from lspci:

00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller

> 
> 
>>3. Sometimes during the search for the suspend hang reason the system
>>   went during suspend into a lightshow of:
>>   eth0: Too much work at interrupt!
>>   and some line that ends in:
>>   release_console_sem+0x13d/0x1c0)
>>   The start of the line is not readable as it just flickers by in
>>   the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
>>   (rev 10). Oh, no chance for a serial console capture as there's no
>>   built in serial device in this laptop.
> 
> 
> How repeatable is that? Will NIC work okay if you rmmod/insmod its driver?
>   Pavel

Happens with a probability of about 10% to 20%. I did comment out the
'Too much work...' printk in r8169.c which results in the following
effect: no more message from the network driver (expected), no other
printk related to release_console_sem or anything else unusal, but write
to disk in the case the problem seems to happen is suddenly quite slow
and suspend eventually succeeds.
As the nic driver is built into the kernel insmod/rmmod currently won't
do:-) Nevertheless there doesn't seem to be any strange behaviour after
resume though I didn't really try to use the nic then.
There is, however, definitely no such problem with the nic in 2.6.11.2.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Andy Isaacson

On Thu, Apr 21, 2005 at 01:39:35PM -0500, Timur Tabi wrote:
> Andy Isaacson wrote:
> >If you take the hardline position that "the app is the only thing that
> >matters", your code is unlikely to get merged.  Linux is a
> >general-purpose OS.
> 
> The problem is that our driver and library implement an API that we don't 
> fully control. The API states that the application allocates the memory and 
> tells the library to register it.  The app then goes on its merry way until 
> it's done, at which point it tells the library to deregister the memory.  
> Neither the app nor the API has any provision for the app to be notified 
> that the memory is no longer pinned and therefore can't be trusted. That 
> would be considered a critical failure from the app's perspective, so the 
> kernel would be doing it a favor by killing the process.

I'm familiar with MPI 1.0 and 2.0, but I haven't been following the
development of modern messaging APIs, so I might not make sense here...

Assuming that the app calls into the library on a fairly regular basis,
you could implement a fast-path/slow-path scheme where the library
normally operates in go-fast mode, but if a "unregister" event has
occurred, the library falls back to a less performant mode.

But now having written that I'm thinking that it's not worth the bother
- if you've got a 512P MPP job, it's basically equivalent to job death
for one of the nodes to go away in this manner -- even if the process is
still running on the node, the fact that you took a giant performance
hiccup is unacceptable.  Therefore, cluster admins are going to do their
darndest to avoid this behavior, so we might as well just kill the job
and make it explicit.

> >You might want to consider what happens with your communication system
> >in a machine running power-saving modes (in the limit, suspend-to-disk).
> >Of course most machines with Infiniband adapters aren't running swsusp,
> >but it's not inconceivable that blade servers might sleep to lower power
> >and cooling costs.
> 
> Any application that registers memory, will in all likelihood be running at 
> 100% CPU non-stop.  The computer is not going to be doing anything else but 
> whatever that app is trying to do.  The application could conceiveable 
> register gigabytes of RAM, and if even a single page becomes unpinned, the 
> whole thing is worthless.  The application cannot do anything meaningful if 
> it gets a message saying that some of the memory has become unpinned and 
> should not be used.
> 
> So the real question is: how important is it to the kernel developers that 
> Linux support these kinds of enterprise-class applications?

While I understand your arguments, this kind of rhetoric is more likely
to harden ears than to convince people you're right.  I refer you to the
"Live Patching Function" thread.

*You* need to come up with a solution that looks good to *the community*
if you want it merged.  In the long run, this process is likely to
result in *your* systems working better than if you had just gone off
and done your thing.  If you have to do something that "tastes bad" to
the average l-k hacker, *justify* it by addressing the alternatives and
explaining why your solution is the right one.

I'm leaning towards agreeing that mlock()-alicious code is the right way
to solve this problem, and it's not clear to me what the benefit of
adding a new VM_REGISTERED flag would be.

Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
pages?  Or are you doing something more nasty?

(Oh, I see that Libor has contributed to the other branch of this
thread... off to read...)

-andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc3-V0.7.46-00

2005-04-21 Thread Daniel Walker

On Thu, 2005-04-21 at 00:35, Ingo Molnar wrote:

> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from 
> [EMAIL PROTECTED]

We had some discussion about this one, there just need to be a softirqd
wakeup , the netif_rx_ni() call isn't really needed .

How about removing the softirqd wakeup from interrupt context, and move
it into the softirq scheduler. That would solve this situation and all
others like it .. Plus reduce worst case interrupt latency ..

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Government Funding Available linux-kernel@vger.kernel.org

2005-04-21 Thread Info

linux-kernel@vger.kernel.org

Press Release

The   is now
available. This guide contains more than 3100 listings
of grants and loans offered by both the federal and 
provincial governments. It also includes foundations and 
associations.


The  
is also available for the United States.


Our publication is sold for $69.95

To order please call:  450-224-yark(9275)



linux-kernel@vger.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11] Documentation [corrected]: remove redundant info from SubmittingPatches

Since the Trivial Patch Monkey is mentioned both in steps 4. and 5., I
removed it from step4 (Select e-mail destination), since it should go
under 'Select your CC list'.

--- linux-2.6.11/Documentation/SubmittingPatches.orig   2005-04-21 
14:17:07.375698154 -0400
+++ linux-2.6.11/Documentation/SubmittingPatches2005-04-21 
15:34:58.588664206 -0400
@@ -132,21 +132,6 @@ which require discussion or do not have 
 usually be sent first to linux-kernel.  Only after the patch is
 discussed should the patch then be submitted to Linus.
 
-For small patches you may want to CC the Trivial Patch Monkey
[EMAIL PROTECTED] set up by Rusty Russell; which collects "trivial"
-patches. Trivial patches must qualify for one of the following rules:
- Spelling fixes in documentation
- Spelling fixes which could break grep(1).
- Warning fixes (cluttering with useless warnings is bad)
- Compilation fixes (only if they are actually correct)
- Runtime fixes (only if they actually fix things)
- Removing use of deprecated functions/macros (eg. check_region).
- Contact detail and documentation fixes
- Non-portable code replaced by portable code (even in arch-specific,
- since people copy, as long as it's trivial)
- Any fix by the author/maintainer of the file. (ie. patch monkey
- in re-transmission mode)
-
 
 
 5) Select your CC (e-mail carbon copy) list.

Signed-off-by: Cosmin Nicolaescu <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Dear diary, on Thu, Apr 21, 2005 at 09:00:09PM CEST, I got a letter
where Pavel Machek <[EMAIL PROTECTED]> told me that...
> Hi!

Hi,

> > > Well, not sure.
> > > 
> > > I did 
> > > 
> > > git track linus
> > > git cancel
> > > 
> > > but Makefile still contains -rc2. (Is "git cancel" right way to check
> > > out the tree?)
> > 
> > No. git cancel does what it says - cancels your local changes to the
> > working tree. git track will only set that next time you pull from
> > linus, the changes will be automatically merged. (Note that this will
> > change with the big UI change.)
> 
> Is there way to say "forget those changes in my repository, I want
> just plain vanilla" without rm -rf?

git cancel will give you "plain last commit". If you need plain vanilla,
the "hard way" now is to just do

commit-id >.git/HEAD

but your current HEAD will be lost forever. Or do

git fork vanilla ~/vanilla linus

and you will have the vanilla tree tracking linus in ~/vanilla.

I'm not yet sure if we should have some Cogito interface for doing this
and what its semantics should be.

> I see quite a lot of problems with fsck-tree. Is that normal?
> (I ran out of disk space few times during different operations...)

Actually, in case your tree is older than about two days, I hope you did
the convert-cache magic or fetched a fresh tree?

-- 
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

2005-04-21 Thread Benoit Boissinot

On 4/21/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 
> 
> Changes since 2.6.12-rc2:
> 
> Benjamin Herrenschmidt:
...
> [PATCH] ppc32: Fix cpufreq problems

this depends on two patches in -mm:

add-suspend-method-to-cpufreq-core.patch
  Add suspend method to cpufreq core

add-suspend-method-to-cpufreq-core-warning-fix.patch
  add-suspend-method-to-cpufreq-core-warning-fix

without those patches defconfig is broken on ppc32

regards,

Benoit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.11] Documentation: correct minor mistake and remove redundant info from SubmittingPatches

2005-04-21 Thread Randy.Dunlap

On Thu, 21 Apr 2005 14:51:09 -0400 Cosmin Nicolaescu wrote:

| The first fix is to reverse the order of the files being diffed. Since
| we make the change in $MYFILE (and not $MYFILE.orig}, the diff should
| have the .orig file first followed by $MYFILE (which has been
| modified).

But the patch below has the .orig file second, not first.
Looks like it's backwards (reversed)

| The second modification is to remove redundant text. The information
| about the Trivial Patch Monkey is both in steps 4 and 5. Since trivial
| should be CCed, the information should only go in step 5 (Select your
| CC list) and be removed from step 4 (Select e-mail destination).

The second patch chunk adds text, not removes it.

| --- linux-2.6.11/Documentation/SubmittingPatches2005-04-21 
14:22:22.242714051 -0400
| +++ linux-2.6.11/Documentation/SubmittingPatches.orig   2005-04-21 
14:17:07.375698154 -0400
| @@ -42,7 +42,7 @@ To create a patch for a single file, it 
| cp $MYFILE $MYFILE.orig
| vi $MYFILE  # make your change
| cd ..
| -   diff -up $SRCTREE/$MYFILE{,.orig} > /tmp/patch
| +   diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
|  
|  To create a patch for multiple files, you should unpack a "vanilla",
|  or unmodified kernel source tree, and generate a diff against your
| @@ -132,6 +132,21 @@ which require discussion or do not have 
|  usually be sent first to linux-kernel.  Only after the patch is
|  discussed should the patch then be submitted to Linus.
|  
| +For small patches you may want to CC the Trivial Patch Monkey
| [EMAIL PROTECTED] set up by Rusty Russell; which collects "trivial"
| +patches. Trivial patches must qualify for one of the following rules:
| + Spelling fixes in documentation
| + Spelling fixes which could break grep(1).
| + Warning fixes (cluttering with useless warnings is bad)
| + Compilation fixes (only if they are actually correct)
| + Runtime fixes (only if they actually fix things)
| + Removing use of deprecated functions/macros (eg. check_region).
| + Contact detail and documentation fixes
| + Non-portable code replaced by portable code (even in arch-specific,
| + since people copy, as long as it's trivial)
| + Any fix by the author/maintainer of the file. (ie. patch monkey
| + in re-transmission mode)
| +

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc3

Hi!

> > > You should put this into .git/remotes
> > > 
> > > linus 
> > > rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> (git addremote is preferred for that :-)

Oops :-).

> > Well, not sure.
> > 
> > I did 
> > 
> > git track linus
> > git cancel
> > 
> > but Makefile still contains -rc2. (Is "git cancel" right way to check
> > out the tree?)
> 
> No. git cancel does what it says - cancels your local changes to the
> working tree. git track will only set that next time you pull from
> linus, the changes will be automatically merged. (Note that this will
> change with the big UI change.)

Is there way to say "forget those changes in my repository, I want
just plain vanilla" without rm -rf?
I see quite a lot of problems with fsck-tree. Is that normal?
(I ran out of disk space few times during different operations...)


-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] generate hotplug events for cpu online

Hi!

> We already do kobject_hotplug for cpu offline; this adds a
> kobject_hotplug call for the online case.  This is being requested by
> developers of an application which wants to be notified about both
> kinds of events.

I'm afraid of bad interactions with swsusp/S3 on smp. We offline cpus there,
but we probably do not want userland to know...

Pavel


-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.12-rc3 compile failure in tgafb.c

2005-04-21 Thread Tomi Lapinlampi


Hi,

2.6.12-rc3 compile fails in drivers/video/tgafb.c

The system is an Alphastation 600 5/266, system variant Alcor,
running Debian Sarge, gcc version 3.3.5 (Debian 1:3.3.5-8)

Btw, the tgafb hasn't really worked on this hardware since 2.6.8.1.
I'll be able to run more tests after this one compiles :)

Regards,

Tomi

% make
  CHK include/linux/version.h
make[1]: `arch/alpha/kernel/asm-offsets.s' is up to date.
  CHK include/asm-alpha/asm_offsets.h
  CHK include/linux/compile.h
  CHK usr/initramfs_list
  CC  drivers/video/tgafb.o
drivers/video/tgafb.c:85: error: `tgafb_pci_unregister' undeclared here (not in 
a function)
drivers/video/tgafb.c:85: error: initializer element is not constant
drivers/video/tgafb.c:85: error: (near initialization for `tgafb_driver.remove')
make[2]: *** [drivers/video/tgafb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2


.config is:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc3
# Thu Apr 21 16:24:40 2005
#
CONFIG_ALPHA=y
CONFIG_64BIT=y
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_GENERIC_IOMAP is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# System setup
#
# CONFIG_ALPHA_GENERIC is not set
CONFIG_ALPHA_ALCOR=y
# CONFIG_ALPHA_XL is not set
# CONFIG_ALPHA_BOOK1 is not set
# CONFIG_ALPHA_AVANTI_CH is not set
# CONFIG_ALPHA_CABRIOLET is not set
# CONFIG_ALPHA_DP264 is not set
# CONFIG_ALPHA_EB164 is not set
# CONFIG_ALPHA_EB64P_CH is not set
# CONFIG_ALPHA_EB66 is not set
# CONFIG_ALPHA_EB66P is not set
# CONFIG_ALPHA_EIGER is not set
# CONFIG_ALPHA_JENSEN is not set
# CONFIG_ALPHA_LX164 is not set
# CONFIG_ALPHA_LYNX is not set
# CONFIG_ALPHA_MARVEL is not set
# CONFIG_ALPHA_MIATA is not set
# CONFIG_ALPHA_MIKASA is not set
# CONFIG_ALPHA_NAUTILUS is not set
# CONFIG_ALPHA_NONAME_CH is not set
# CONFIG_ALPHA_NORITAKE is not set
# CONFIG_ALPHA_PC164 is not set
# CONFIG_ALPHA_P2K is not set
# CONFIG_ALPHA_RAWHIDE is not set
# CONFIG_ALPHA_RUFFIAN is not set
# CONFIG_ALPHA_RX164 is not set
# CONFIG_ALPHA_SX164 is not set
# CONFIG_ALPHA_SABLE is not set
# CONFIG_ALPHA_SHARK is not set
# CONFIG_ALPHA_TAKARA is not set
# CONFIG_ALPHA_TITAN is not set
# CONFIG_ALPHA_WILDFIRE is not set
CONFIG_ISA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_ALPHA_EV5=y
CONFIG_ALPHA_CIA=y
# CONFIG_ALPHA_EV56 is not set
# CONFIG_ALPHA_SRM is not set
CONFIG_EISA=y
# CONFIG_DISCONTIGMEM is not set
CONFIG_VERBOSE_MCHECK=y
CONFIG_VERBOSE_MCHECK_ON=1
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
CONFIG_EISA_PCI_EISA=y
# CONFIG_EISA_VIRTUAL_ROOT is not set
# CONFIG_EISA_NAMES is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
CONFIG_SRM_ENV=m
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_EM86 is not set
# CONFIG_BINFMT_MISC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#

[PATCH 2.6.11] Documentation: correct minor mistake and remove redundant info from SubmittingPatches

The first fix is to reverse the order of the files being diffed. Since
we make the change in $MYFILE (and not $MYFILE.orig}, the diff should
have the .orig file first followed by $MYFILE (which has been
modified).

The second modification is to remove redundant text. The information
about the Trivial Patch Monkey is both in steps 4 and 5. Since trivial
should be CCed, the information should only go in step 5 (Select your
CC list) and be removed from step 4 (Select e-mail destination).

--- linux-2.6.11/Documentation/SubmittingPatches2005-04-21 
14:22:22.242714051 -0400
+++ linux-2.6.11/Documentation/SubmittingPatches.orig   2005-04-21 
14:17:07.375698154 -0400
@@ -42,7 +42,7 @@ To create a patch for a single file, it 
cp $MYFILE $MYFILE.orig
vi $MYFILE  # make your change
cd ..
-   diff -up $SRCTREE/$MYFILE{,.orig} > /tmp/patch
+   diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
 
 To create a patch for multiple files, you should unpack a "vanilla",
 or unmodified kernel source tree, and generate a diff against your
@@ -132,6 +132,21 @@ which require discussion or do not have 
 usually be sent first to linux-kernel.  Only after the patch is
 discussed should the patch then be submitted to Linus.
 
+For small patches you may want to CC the Trivial Patch Monkey
[EMAIL PROTECTED] set up by Rusty Russell; which collects "trivial"
+patches. Trivial patches must qualify for one of the following rules:
+ Spelling fixes in documentation
+ Spelling fixes which could break grep(1).
+ Warning fixes (cluttering with useless warnings is bad)
+ Compilation fixes (only if they are actually correct)
+ Runtime fixes (only if they actually fix things)
+ Removing use of deprecated functions/macros (eg. check_region).
+ Contact detail and documentation fixes
+ Non-portable code replaced by portable code (even in arch-specific,
+ since people copy, as long as it's trivial)
+ Any fix by the author/maintainer of the file. (ie. patch monkey
+ in re-transmission mode)
+
 
 
 5) Select your CC (e-mail carbon copy) list.

Signed-off-by: Cosmin Nicolaescu <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.11.7 / CLPS711x/SkyMinder] module integration issue: keyboard driver _still_ not working after port from 2.4.27

2005-04-21 Thread Luke Kenneth Casson Leighton

okay - i found this:

http://seclists.org/lists/linux-kernel/2000/Mar/0093.html

it talks about "we must force people to choose between vgacon and
fbcon".

when that forcing decision was taken, was dual fbcon-and-serial-console
usage taken into account?

booting with . console=ttyCL1 fbcon=vc:1 and then later
on doing modprobe fbcon has exactly the same consequences:
fbcon_takeover is called, the fbcon=vc:1 parameters appear to
be ignored graat.

how the _heck_ am i gonna over-ride the fb_console "setup"
paramaters on a module load, to stop this happening???

i know - HACK TIME!!!

muhahahahah.

l.

On Thu, Apr 21, 2005 at 07:28:45PM +0100, Luke Kenneth Casson Leighton wrote:

> in order to be able to debug what is going on, i have enabled 
> a dummy/virtual serial console, all is well so far.
> 
> in order to test the screen, i have written, enabled, tested,
> confirmed as reasonably working, a framebuffer driver (which
> i would like to make the console framebuffer - eventually -
> when the serial console is disabled and no longer needed -
> so i am enabling Framebuffer Console support AS WELL as serial
> console support)
> 
> now i load the keyboard event module... splat - absolutely no response:
> complete lock-up.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11] Documentation: remove super-{nr, max} from the Documentation to reflect fs/super.c