Re: cpufreq on-demand governor up_treshold?

2005-03-14 Thread Eric Piel
Jan De Luyck a écrit :
Hello lists,
(please cc me from cpufreq list)
I've since yesterday started using the ondemand governor. Seems to work fine, 
tho I can't seem to find a reason why it keeps scaling my processor speed 
upwards tho the processor use never exceeds 30% (been watching top -d 1). 
:
:
Any hints?
You can try the three attached patches in the order :
ondemand-cleanup-factorise-idle-measurement-2.6.11.patch
ondemand-save-idle-up-for-all-cpu-2.6.11.patch
ondemand-automatic-downscaling-2.6.11-accepted.patch
They are available on the cpufreq list but as it's difficult to access 
it I'm sending them again, all together. These are the last things that 
Venki and I have been working on. It should solve your problem 
(actually, only the last patch, but it depends on the two previous 
patches). Please, let me know if it works.

BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot 
available at codemonkey.org.uk. Should I worry, or is it just due to 
some latency between your private trees and the public one?

Eric
diff -purN linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.11/drivers/cpufreq/cpufreq_ondemand.c	2005-03-07 17:57:31.0 -0800
+++ linux-2.6.11-new/drivers/cpufreq/cpufreq_ondemand.c	2005-03-07 17:53:17.0 -0800
@@ -34,13 +34,9 @@
  */
 
 #define DEF_FREQUENCY_UP_THRESHOLD		(80)
-#define MIN_FREQUENCY_UP_THRESHOLD		(0)
+#define MIN_FREQUENCY_UP_THRESHOLD		(10)
 #define MAX_FREQUENCY_UP_THRESHOLD		(100)
 
-#define DEF_FREQUENCY_DOWN_THRESHOLD		(20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD		(0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD		(100)
-
 /* 
  * The polling frequency of this governor depends on the capability of 
  * the processor. Default polling frequency is 1000 times the transition
@@ -78,12 +74,10 @@ struct dbs_tuners {
 	unsigned int 		sampling_rate;
 	unsigned int		sampling_down_factor;
 	unsigned int		up_threshold;
-	unsigned int		down_threshold;
 };
 
 static struct dbs_tuners dbs_tuners_ins = {
 	.up_threshold 		= DEF_FREQUENCY_UP_THRESHOLD,
-	.down_threshold 	= DEF_FREQUENCY_DOWN_THRESHOLD,
 	.sampling_down_factor 	= DEF_SAMPLING_DOWN_FACTOR,
 };
 
@@ -115,7 +109,6 @@ static ssize_t show_##file_name		\
 show_one(sampling_rate, sampling_rate);
 show_one(sampling_down_factor, sampling_down_factor);
 show_one(up_threshold, up_threshold);
-show_one(down_threshold, down_threshold);
 
 static ssize_t store_sampling_down_factor(struct cpufreq_policy *unused, 
 		const char *buf, size_t count)
@@ -161,8 +154,7 @@ static ssize_t store_up_threshold(struct
 
 	down(dbs_sem);
 	if (ret != 1 || input  MAX_FREQUENCY_UP_THRESHOLD || 
-			input  MIN_FREQUENCY_UP_THRESHOLD ||
-			input = dbs_tuners_ins.down_threshold) {
+			input  MIN_FREQUENCY_UP_THRESHOLD) {
 		up(dbs_sem);
 		return -EINVAL;
 	}
@@ -173,26 +165,6 @@ static ssize_t store_up_threshold(struct
 	return count;
 }
 
-static ssize_t store_down_threshold(struct cpufreq_policy *unused, 
-		const char *buf, size_t count)
-{
-	unsigned int input;
-	int ret;
-	ret = sscanf (buf, %u, input);
-
-	down(dbs_sem);
-	if (ret != 1 || input  MAX_FREQUENCY_DOWN_THRESHOLD || 
-			input  MIN_FREQUENCY_DOWN_THRESHOLD ||
-			input = dbs_tuners_ins.up_threshold) {
-		up(dbs_sem);
-		return -EINVAL;
-	}
-
-	dbs_tuners_ins.down_threshold = input;
-	up(dbs_sem);
-
-	return count;
-}
 
 #define define_one_rw(_name) \
 static struct freq_attr _name = \
@@ -201,7 +173,6 @@ __ATTR(_name, 0644, show_##_name, store_
 define_one_rw(sampling_rate);
 define_one_rw(sampling_down_factor);
 define_one_rw(up_threshold);
-define_one_rw(down_threshold);
 
 static struct attribute * dbs_attributes[] = {
 	sampling_rate_max.attr,
@@ -209,7 +180,6 @@ static struct attribute * dbs_attributes
 	sampling_rate.attr,
 	sampling_down_factor.attr,
 	up_threshold.attr,
-	down_threshold.attr,
 	NULL
 };
 
@@ -222,8 +192,8 @@ static struct attribute_group dbs_attr_g
 
 static void dbs_check_cpu(int cpu)
 {
-	unsigned int idle_ticks, up_idle_ticks, down_idle_ticks;
-	unsigned int freq_down_step;
+	unsigned int idle_ticks, up_idle_ticks, total_ticks;
+	unsigned int freq_next;
 	unsigned int freq_down_sampling_rate;
 	static int down_skip[NR_CPUS];
 	struct cpu_dbs_info_s *this_dbs_info;
@@ -290,7 +260,12 @@ static void dbs_check_cpu(int cpu)
 	down_skip[cpu]++;
 	if (down_skip[cpu]  dbs_tuners_ins.sampling_down_factor)
 		return;
+	down_skip[cpu] = 0;
 
+	/* don't try to decrease the frequency if it's already the min */
+	if (policy-cur == policy-min)
+		return;
+	
 	idle_ticks = UINT_MAX;
 	for_each_cpu_mask(j, policy-cpus) {
 		unsigned int tmp_idle_ticks, total_idle_ticks;
@@ -308,27 +283,23 @@ static void dbs_check_cpu(int cpu)
 			idle_ticks = tmp_idle_ticks;
 	}
 
-	/* Scale idle ticks by 100 and compare with up and down ticks */
-	idle_ticks *= 100;
-	down_skip[cpu] = 0;
-
+	/* Compute how many ticks there are between two measurements */
 	freq_down_sampling_rate = 

Re: Call for help: list of machines with working S3

2005-03-14 Thread Pavel Machek
Hi!

   * MySQL (hinders the actual suspension process and kicks the pc back to 
 where it was)

Try this patch...
Pavel

--- clean/kernel/signal.c   2005-02-03 22:27:26.0 +0100
+++ linux/kernel/signal.c   2005-02-03 22:28:19.0 +0100
@@ -,6 +,7 @@
ret = -EINTR;
}
 
+   try_to_freeze(1);
return ret;
 }
 


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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] break_lock forever broken

2005-03-14 Thread Nick Piggin
Ingo Molnar wrote:
* Hugh Dickins [EMAIL PROTECTED] wrote:

@@ -187,6 +187,8 @@ void __lockfunc _##op##_lock(locktype##_
cpu_relax();\
preempt_disable();  \
}   \
+   if ((lock)-break_lock)  \
+   (lock)-break_lock = 0;  \

while writing the -break_lock feature i intentionally avoided overhead
in the spinlock fastpath. A better solution for the bug you noticed is
to clear the break_lock flag in places that use need_lock_break()
explicitly.
What happens if break_lock gets set by random contention on the
lock somewhere (with no need_lock_break or cond_resched_lock)?
Next time it goes through a lockbreak will (may) be a false positive.
I think I'd prefer the additional lock overhead of Hugh's patch if
it gives better behaviour. I think. Any idea what the overhead actually
is?
One robust way for that seems to be to make the need_lock_break() macro
clear the flag if it sees it set, and to make all the other (internal)
users use __need_lock_break() that doesnt clear the flag. I'll cook up a
patch for this.
If you do this exactly as you describe, then you'll break
cond_resched_lock (eg. for the copy_page_range path), won't you?
-
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] ppc64: kill might_sleep() warnings in __copy_*_user_inatomic

2005-03-14 Thread Paul Mackerras
This patch is from Arnd Bergmann and Olof Johansson.

This implements the __copy_{to,from}_user_inatomic() functions on ppc64.
The only difference between the inatomic and regular version is that
inatomic does not call might_sleep() to detect possible faults while
holding locks/elevated preempt counts.

Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

--- linux-2.6-ppc.orig/include/asm-ppc64/uaccess.h  2005-03-10 
14:54:18.0 -0500
+++ linux-2.6-ppc/include/asm-ppc64/uaccess.h   2005-03-11 06:55:02.792926304 
-0500
@@ -119,6 +119,7 @@ extern long __put_user_bad(void);
 #define __put_user_nocheck(x,ptr,size) \
 ({ \
long __pu_err;  \
+   might_sleep();  \
__chk_user_ptr(ptr);\
__put_user_size((x),(ptr),(size),__pu_err,-EFAULT); \
__pu_err;   \
@@ -128,6 +129,7 @@ extern long __put_user_bad(void);
 ({ \
long __pu_err = -EFAULT;\
void __user *__pu_addr = (ptr); \
+   might_sleep();  \
if (access_ok(VERIFY_WRITE,__pu_addr,size)) \
__put_user_size((x),__pu_addr,(size),__pu_err,-EFAULT); \
__pu_err;   \
@@ -135,7 +137,6 @@ extern long __put_user_bad(void);
 
 #define __put_user_size(x,ptr,size,retval,errret)  \
 do {   \
-   might_sleep();  \
retval = 0; \
switch (size) { \
  case 1: __put_user_asm(x,ptr,retval,stb,errret); break; \
@@ -170,6 +171,7 @@ do {
\
 #define __get_user_nocheck(x,ptr,size) \
 ({ \
long __gu_err, __gu_val;\
+   might_sleep();  \
__get_user_size(__gu_val,(ptr),(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err;   \
@@ -179,6 +181,7 @@ do {
\
 ({ \
long __gu_err = -EFAULT, __gu_val = 0;  \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+   might_sleep();  \
if (access_ok(VERIFY_READ,__gu_addr,size))  \
__get_user_size(__gu_val,__gu_addr,(size),__gu_err,-EFAULT);\
(x) = (__typeof__(*(ptr)))__gu_val; \
@@ -189,7 +192,6 @@ extern long __get_user_bad(void);
 
 #define __get_user_size(x,ptr,size,retval,errret)  \
 do {   \
-   might_sleep();  \
retval = 0; \
__chk_user_ptr(ptr);\
switch (size) { \
@@ -223,9 +225,8 @@ extern unsigned long __copy_tofrom_user(
unsigned long size);
 
 static inline unsigned long
-__copy_from_user(void *to, const void __user *from, unsigned long n)
+__copy_from_user_inatomic(void *to, const void __user *from, unsigned long n)
 {
-   might_sleep();
if (__builtin_constant_p(n)) {
unsigned long ret;
 
@@ -248,9 +249,15 @@ __copy_from_user(void *to, const void __
 }
 
 static inline unsigned long
-__copy_to_user(void __user *to, const void *from, unsigned long n)
+__copy_from_user(void *to, const void __user *from, unsigned long n)
 {
might_sleep();
+   return __copy_from_user_inatomic(to, from, n);
+}
+
+static inline unsigned long
+__copy_to_user_inatomic(void __user *to, const void *from, unsigned long n)
+{
if (__builtin_constant_p(n)) {
unsigned long ret;
 
@@ -272,6 +279,13 @@ __copy_to_user(void __user *to, const vo
return __copy_tofrom_user(to, (__force const void __user *) from, n);
 }
 
+static inline unsigned long
+__copy_to_user(void 

Re: [PATCH] break_lock forever broken

2005-03-14 Thread Ingo Molnar

* Nick Piggin [EMAIL PROTECTED] wrote:

  while writing the -break_lock feature i intentionally avoided
  overhead in the spinlock fastpath. A better solution for the bug you
  noticed is to clear the break_lock flag in places that use
  need_lock_break() explicitly.
 
 What happens if break_lock gets set by random contention on the lock
 somewhere (with no need_lock_break or cond_resched_lock)? Next time it
 goes through a lockbreak will (may) be a false positive.

yes, and that's harmless. Lock contention is supposed to be a relatively
rare thing (compared to the frequency of uncontended locking), so all
the overhead is concentrated towards the contention case, not towards
the uncontended case. If the flag lingers then it may be a false
positive and the lock will be dropped once, the flag will be cleared,
and the lock will be reacquired. So we've traded a constant amount of
overhead in the fastpath for a somewhat higher, but still constant
amount of overhead in the slowpath.

 One robust way for that seems to be to make the need_lock_break() macro
 clear the flag if it sees it set, and to make all the other (internal)
 users use __need_lock_break() that doesnt clear the flag. I'll cook up a
 patch for this.
 
 
 If you do this exactly as you describe, then you'll break
 cond_resched_lock (eg. for the copy_page_range path), won't you?

(cond_resched_lock() is an 'internal' user that will use
__need_lock_break().)

Ingo
-
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: AGP bogosities

2005-03-14 Thread Pavel Machek
On Pá 11-03-05 17:26:14, Dave Jones wrote:
 On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote:
   Linus Torvalds [EMAIL PROTECTED] writes:
   
Hmm.. We seem to not have any tests for the counts becoming negative, and
this would seem to be an easy mistake to make considering that both I 
 and 
Dave did it.
   
   I stole this from -mm.
 
 I'm fascinated that not a single person picked up on this problem
 whilst the agp code sat in -mm. Even if DRI isn't enabled,
 every box out there with AGP that uses the generic routines
 (which is a majority), should have barfed loudly when it hit
 this check during boot.  Does no-one read dmesg output any more ?

Its way too long these days. Like so long it overflows even enlarged
buffer. We should prune these messages down to one line per hw
device or serious problems only.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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] IBM TrackPoint support

2005-03-14 Thread Vojtech Pavlik
On Mon, Mar 14, 2005 at 12:02:13AM -0500, Stephen Evanchik wrote:

 Here's the latest patch for TracKPoint devices. I have changed the
 sysfs filenames to be more descriptive for commonly used attributes. I
 also implemented the set_properties flag for initialization.
 
 It patches against 2.6.11 and 2.6.11.3 however I have not tested it
 with 2.6.11.3 .
 
 Any comments are appreciated.

 +/*
 + * Mode manipulation
 + */
 +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */
 +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */
 +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */

What exactly is transparent mode? 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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] break_lock forever broken

2005-03-14 Thread Nick Piggin
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:

while writing the -break_lock feature i intentionally avoided
overhead in the spinlock fastpath. A better solution for the bug you
noticed is to clear the break_lock flag in places that use
need_lock_break() explicitly.
What happens if break_lock gets set by random contention on the lock
somewhere (with no need_lock_break or cond_resched_lock)? Next time it
goes through a lockbreak will (may) be a false positive.

yes, and that's harmless. Lock contention is supposed to be a relatively
rare thing (compared to the frequency of uncontended locking), so all
the overhead is concentrated towards the contention case, not towards
the uncontended case. If the flag lingers then it may be a false
positive and the lock will be dropped once, the flag will be cleared,
and the lock will be reacquired. So we've traded a constant amount of
overhead in the fastpath for a somewhat higher, but still constant
amount of overhead in the slowpath.
Yes that's the tradeoff. I just feel that the former may be better,
especially because the latter can be timing dependant (so you may get
things randomly happening), and the former is apparently very low
overhead compared with the cost of taking the lock. Any numbers,
anyone?

One robust way for that seems to be to make the need_lock_break() macro
clear the flag if it sees it set, and to make all the other (internal)
users use __need_lock_break() that doesnt clear the flag. I'll cook up a
patch for this.
If you do this exactly as you describe, then you'll break
cond_resched_lock (eg. for the copy_page_range path), won't you?

(cond_resched_lock() is an 'internal' user that will use
__need_lock_break().)
Off the top of my head, this is what it looks like:
spin_lock(dst-lock);
spin_lock(src-lock);
for (lots of stuff) {
if (need_lock_break(src-lock) || need_lock_break(dst-lock))
break;
}
spin_unlock(src-lock);
cond_resched_lock(dst-lock);
Right? Now currently the src-lock is broken, but your change would break
the cond_resched_lock here, it will not trigger because need_lock_break
clears dst-lock... oh I see, the spinning CPU will set it again. Yuck :(
-
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: AGP bogosities

2005-03-14 Thread David Lang
On Mon, 14 Mar 2005, Pavel Machek wrote:
I'm fascinated that not a single person picked up on this problem
whilst the agp code sat in -mm. Even if DRI isn't enabled,
every box out there with AGP that uses the generic routines
(which is a majority), should have barfed loudly when it hit
this check during boot.  Does no-one read dmesg output any more ?
Its way too long these days. Like so long it overflows even enlarged
buffer. We should prune these messages down to one line per hw
device or serious problems only.
especially if you turn on encryption options. I can understand that output 
being useful for debugging, but there should be a way to not deal with it 
in the normal case.

David Lang
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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] break_lock forever broken

2005-03-14 Thread Arjan van de Ven

 
 Yes that's the tradeoff. I just feel that the former may be better,
 especially because the latter can be timing dependant (so you may get
 things randomly happening), and the former is apparently very low
 overhead compared with the cost of taking the lock. Any numbers,
 anyone?

as I said, since the cacheline just got dirtied, the write is just half
a cycle which is so much in the noise that it really doesn't matter.


-
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/


dmesg verbosity [was Re: AGP bogosities]

2005-03-14 Thread Pavel Machek
Hi!

 I'm fascinated that not a single person picked up on this problem
 whilst the agp code sat in -mm. Even if DRI isn't enabled,
 every box out there with AGP that uses the generic routines
 (which is a majority), should have barfed loudly when it hit
 this check during boot.  Does no-one read dmesg output any more ?
 
 Its way too long these days. Like so long it overflows even enlarged
 buffer. We should prune these messages down to one line per hw
 device or serious problems only.
 
 especially if you turn on encryption options. I can understand that output 
 being useful for debugging, but there should be a way to not deal with it 
 in the normal case.

Perhaps we could have a rule like

non-experimental driver may only print out one line per actual
device?

(and perhaps: dmesg output for boot going okay should fit on one screen).

Or perhaps we should have warnings-like regression testing.

New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg
junk.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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] break_lock forever broken

2005-03-14 Thread Nick Piggin
Arjan van de Ven wrote:
Yes that's the tradeoff. I just feel that the former may be better,
especially because the latter can be timing dependant (so you may get
things randomly happening), and the former is apparently very low
overhead compared with the cost of taking the lock. Any numbers,
anyone?

as I said, since the cacheline just got dirtied, the write is just half
a cycle which is so much in the noise that it really doesn't matter.
Yes, you were the apparently that I cited :)
I just wondered if Ingo has or has seen numbers that make
him dislike this way of doing it.
I would have thought that the spinlock structure and code bloat,
and the lock break checks in fast paths would be the far greater
cost of lockbreak than what Hugh's patch adds. But real numbers
are pretty important when it comes to this kind of thing.
-
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] PPC64 Make RTAS code usable on non-pSeries machines

2005-03-14 Thread Paul Mackerras
This patch is from Arnd Bergmann [EMAIL PROTECTED].

RTAS is not actually pSeries specific, but some PPC64 code that relies
on RTAS is currently protected by CONFIG_PPC_PSERIES.
This introduces a generic configuration option PPC_RTAS that can be used
by other subarchitectures as well. The existing option with the same
name is renamed to the more specific RTAS_PROC.

Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

diff -urN linux-2.5/arch/ppc64/Kconfig test/arch/ppc64/Kconfig
--- linux-2.5/arch/ppc64/Kconfig2005-03-14 08:25:07.0 +1100
+++ test/arch/ppc64/Kconfig 2005-03-14 19:31:22.0 +1100
@@ -255,16 +255,21 @@
 
 
 config PPC_RTAS
-   bool Proc interface to RTAS
+   bool
depends on PPC_PSERIES
+   default y
+
+config RTAS_PROC
+   bool Proc interface to RTAS
+   depends on PPC_RTAS
 
 config RTAS_FLASH
tristate Firmware flash interface
-   depends on PPC_RTAS
+   depends on RTAS_PROC
 
 config SCANLOG
tristate Scanlog dump interface
-   depends on PPC_RTAS
+   depends on RTAS_PROC  PPC_PSERIES
 
 config LPARCFG
tristate LPAR Configuration Data
diff -urN linux-2.5/arch/ppc64/kernel/Makefile test/arch/ppc64/kernel/Makefile
--- linux-2.5/arch/ppc64/kernel/Makefile2005-03-07 08:21:53.0 
+1100
+++ test/arch/ppc64/kernel/Makefile 2005-03-14 19:31:22.0 +1100
@@ -39,7 +39,7 @@
 obj-$(CONFIG_RTAS_FLASH)   += rtas_flash.o
 obj-$(CONFIG_SMP)  += smp.o
 obj-$(CONFIG_MODULES)  += module.o ppc_ksyms.o
-obj-$(CONFIG_PPC_RTAS) += rtas-proc.o
+obj-$(CONFIG_RTAS_PROC)+= rtas-proc.o
 obj-$(CONFIG_SCANLOG)  += scanlog.o
 obj-$(CONFIG_VIOPATH)  += viopath.o
 obj-$(CONFIG_LPARCFG)  += lparcfg.o
diff -urN linux-2.5/arch/ppc64/kernel/entry.S test/arch/ppc64/kernel/entry.S
--- linux-2.5/arch/ppc64/kernel/entry.S 2005-02-07 07:55:28.0 +1100
+++ test/arch/ppc64/kernel/entry.S  2005-03-14 19:31:22.0 +1100
@@ -616,7 +616,7 @@
bl  .unrecoverable_exception
b   unrecov_restore
 
-#ifdef CONFIG_PPC_PSERIES
+#ifdef CONFIG_PPC_RTAS
 /*
  * On CHRP, the Run-Time Abstraction Services (RTAS) have to be
  * called with the MMU off.
@@ -753,7 +753,7 @@
mtlrr0
 blr/* return to caller */
 
-#endif /* CONFIG_PPC_PSERIES */
+#endif /* CONFIG_PPC_RTAS */
 
 #ifdef CONFIG_PPC_MULTIPLATFORM
 
diff -urN linux-2.5/arch/ppc64/kernel/misc.S test/arch/ppc64/kernel/misc.S
--- linux-2.5/arch/ppc64/kernel/misc.S  2005-03-14 08:25:07.0 +1100
+++ test/arch/ppc64/kernel/misc.S   2005-03-14 19:31:22.0 +1100
@@ -680,7 +680,7 @@
ld  r30,-16(r1)
blr
 
-#ifndef CONFIG_PPC_PSERIES /* hack hack hack */
+#ifdef CONFIG_PPC_RTAS /* hack hack hack */
 #define ppc_rtas   sys_ni_syscall
 #endif
 
diff -urN linux-2.5/arch/ppc64/kernel/prom.c test/arch/ppc64/kernel/prom.c
--- linux-2.5/arch/ppc64/kernel/prom.c  2005-03-10 09:14:12.0 +1100
+++ test/arch/ppc64/kernel/prom.c   2005-03-14 19:31:22.0 +1100
@@ -894,7 +894,7 @@
if (get_flat_dt_prop(node, linux,iommu-force-on, NULL) != NULL)
iommu_force_on = 1;
 
-#ifdef CONFIG_PPC_PSERIES
+#ifdef CONFIG_PPC_RTAS
/* To help early debugging via the front panel, we retreive a minimal
 * set of RTAS infos now if available
 */
@@ -910,7 +910,7 @@
rtas.size = *prop;
}
}
-#endif /* CONFIG_PPC_PSERIES */
+#endif /* CONFIG_PPC_RTAS */
 
/* break now */
return 1;
diff -urN linux-2.5/arch/ppc64/kernel/rtc.c test/arch/ppc64/kernel/rtc.c
--- linux-2.5/arch/ppc64/kernel/rtc.c   2004-11-17 09:38:21.0 +1100
+++ test/arch/ppc64/kernel/rtc.c2005-03-14 19:31:22.0 +1100
@@ -337,7 +337,7 @@
 }
 #endif
 
-#ifdef CONFIG_PPC_PSERIES
+#ifdef CONFIG_PPC_RTAS
 #define MAX_RTC_WAIT 5000  /* 5 sec */
 #define RTAS_CLOCK_BUSY (-2)
 void pSeries_get_boot_time(struct rtc_time *rtc_tm)
diff -urN linux-2.5/arch/ppc64/kernel/setup.c test/arch/ppc64/kernel/setup.c
--- linux-2.5/arch/ppc64/kernel/setup.c 2005-03-07 08:21:53.0 +1100
+++ test/arch/ppc64/kernel/setup.c  2005-03-14 19:31:22.0 +1100
@@ -605,12 +605,12 @@
 */
initialize_cache_info();
 
-#ifdef CONFIG_PPC_PSERIES
+#ifdef CONFIG_PPC_RTAS
/*
 * Initialize RTAS if available
 */
rtas_initialize();
-#endif /* CONFIG_PPC_PSERIES */
+#endif /* CONFIG_PPC_RTAS */
 
/*
 * Check if we have an initrd provided via the device-tree
diff -urN linux-2.5/arch/ppc64/oprofile/op_model_power4.c 
test/arch/ppc64/oprofile/op_model_power4.c
--- linux-2.5/arch/ppc64/oprofile/op_model_power4.c 2005-03-07 
08:21:53.0 +1100
+++ test/arch/ppc64/oprofile/op_model_power4.c  2005-03-14 19:31:22.0 
+1100

Re: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-14 Thread Greg Stark

 Greg Stark [EMAIL PROTECTED] writes:
 
  Andrew Morton [EMAIL PROTECTED] writes:
  
   Are you able to narrow it down to something more fine grained than 
   between
   2.6.6 and 2.6.9-rc1?
  
  Er, I suppose I would have to build some more kernels. Ugh. Is there a good
  place to start or do I have to just do a binary search?

Well, I built a slew of kernels but found it on the first reboot.

2.6.7 doesn't work.

I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load them.




 
 2.6.7:
 
 [EMAIL PROTECTED]
   [PATCH] I2C: ICH6/6300ESB i2c support
   
   This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus).
   In order to add this support I needed to patch pci_ids.h with the SMBus
   DID's.  To keep things orginized I renumbered the ICH6 and ESB entries
   in pci_ids.h.  I then patched the piix IDE and i810 audio drivers to
   reflect the updated #define's.  I also removed an error from irq.c;
   there was a reference to a 6300ESB DID that does not exist.
 
 [EMAIL PROTECTED]
   [sound/oss i810] pci id cleanups
   
   The driver defined its own PCI id constants.  Kill the majority,
   which were redundant, and move the rest to include/linux/pci_ids.h.
   
   Also, move open-coded tests for new ICH audio chips to a single
   helper function.  These tests were being patched with each new
   ICH motherboard from Intel, resulting in each new PCI id being added
   to several places in the driver.
   
   Note that, even though this should be a harmless patch, there
   exists the remote possibility that I mis-matched some of the
   PCI ids, as I only tested ICH5.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix wait queue race in drain_dac
   
   This particular one fixes a textbook race condition in drain_dac
   that causes it to timeout when it shouldn't.
 [EMAIL PROTECTED]
   [sound/oss i810] fix race
   
   This patch fixes the value of swptr in case of an underrun/overrun.
   
   Overruns/underruns probably won't occur at all when the driver is
   fixed properly, but this doesn't hurt.
 
 [EMAIL PROTECTED]
   [sound/oss] remove bogus CIV_TO_LVI
   
   This patch removes a pair of bogus LVI assignments.  The explanation in
   the comment is wrong because the value of PCIB tells the hardware that
   the DMA buffer can be processed even if LVI == CIV.
   
   Setting LVI to CIV + 1 causes overruns when with short writes
   (something that vmware is very fond of).
 
 [EMAIL PROTECTED]
   [sound/oss i810] clean up with macros
   
   This patch adds a number macros to clean up the code.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix partial DMA transfers
   
   This patch fixes a longstanding bug in this driver where partial 
 fragments
   are fed to the hardware.  Worse yet, those fragments are then extended
   while the hardware is doing DMA transfers causing all sorts of problems.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix playback SETTRIGGER
   
   This patch fixes SETTRIGGER with playback so that the LVI is always
   set and the DAC is always started.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix OSS fragments
   
   This patch makes userfragsize do what it's meant to do: do not start
   DAC/ADC until a full fragment is available.
 
 [EMAIL PROTECTED]
   [sound/oss i810] remove divides on playback
   
   This patch removes a couple of divides on the playback path.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix drain_dac loop when signals_allowed==0
   
   This patch fixes another bug in the drain_dac wait loop when it is
   called with signals_allowed == 0.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix reads/writes % 4 != 0
   
   This patch removes another bogus chunk of code that breaks when
   the application does a partial write.
   
   In particular, a read/write of x bytes where x % 4 != 0 will loop 
 forever.
 
 [EMAIL PROTECTED]
   [sound/oss i810] fix deadlock in drain_dac
   
   This patch fixes a typo in a previous change that causes the driver
   to deadlock under SMP.

-- 
greg

-
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/


pam and nice-rt-prio-rlimits

2005-03-14 Thread Vegard Lima
Hello,

in the long thread on [request for inclusion] Realtime LSM there
doesn't appear to be too many people who has actually tested the
nice-and-rt-prio-rlimits.patch. Well, it works for me...

However, the patch to pam_limits posted here:
  http://lkml.org/lkml/2005/1/14/174
is a little bit aggressive on the semi-colon side.

Tested patch (and pam.src.rpm for fedora c3) can be found here
  http://home.hia.no/~vegardl/rlimit/
and below

--- Linux-PAM-0.77/modules/pam_limits/pam_limits.c.rtprio   2005-03-13 
16:15:07.0 +0100
+++ Linux-PAM-0.77/modules/pam_limits/pam_limits.c  2005-03-13 
16:27:54.0 +0100
@@ -39,6 +39,11 @@
 #include grp.h
 #include pwd.h
 
+/* Hack to test new rlimit values */
+#define RLIMIT_NICE13
+#define RLIMIT_RTPRIO  14
+#define RLIM_NLIMITS   15
+
 /* Module defines */
 #define LINE_LENGTH 1024
 
@@ -293,6 +298,10 @@
 else if (strcmp(lim_item, locks) == 0)
limit_item = RLIMIT_LOCKS;
 #endif
+else if (strcmp(lim_item, rt_priority) == 0)
+   limit_item = RLIMIT_RTPRIO;
+else if (strcmp(lim_item, nice) == 0)
+   limit_item = RLIMIT_NICE;
 else if (strcmp(lim_item, maxlogins) == 0) {
limit_item = LIMIT_LOGIN;
pl-flag_numsyslogins = 0;
@@ -360,6 +369,18 @@
 case RLIMIT_AS:
 limit_value *= 1024;
 break;
+case RLIMIT_NICE:
+if (limit_value  39)
+   limit_value = 39;
+   if (limit_value  0)
+   limit_value = 0;
+break;
+case RLIMIT_RTPRIO:
+if (limit_value  99)
+   limit_value = 99;
+   if (limit_value  0)
+   limit_value = 0;
+break;
 }
 
 if ( (limit_item != LIMIT_LOGIN)



Thanks,
-- 
Vegard Lima


-
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 1/1] Fix kconfig docs typo: integer - int

2005-03-14 Thread blaisorblade

Trivial correction: the type of numbers for Kconfig is not integer but int (I
just verified because I followed the wrong docs and got a error, I looked
elsewhere and they are using int, and int works for me). Please apply.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/Documentation/kbuild/kconfig-language.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN Documentation/kbuild/kconfig-language.txt~doc-big-typo-fix 
Documentation/kbuild/kconfig-language.txt
--- linux-2.6.11/Documentation/kbuild/kconfig-language.txt~doc-big-typo-fix 
2005-03-10 16:35:38.0 +0100
+++ linux-2.6.11-paolo/Documentation/kbuild/kconfig-language.txt
2005-03-10 16:36:09.0 +0100
@@ -48,7 +48,7 @@ Menu attributes
 A menu entry can have a number of attributes. Not all of them are
 applicable everywhere (see syntax).
 
-- type definition: bool/tristate/string/hex/integer
+- type definition: bool/tristate/string/hex/int
   Every config option must have a type. There are only two basic types:
   tristate and string, the other types are based on these two. The type
   definition optionally accepts an input prompt, so these two examples
@@ -100,7 +100,7 @@ applicable everywhere (see syntax).
   symbols.
 
 - numerical ranges: range symbol symbol [if expr]
-  This allows to limit the range of possible input values for integer
+  This allows to limit the range of possible input values for int
   and hex symbols. The user can only input a value which is larger than
   or equal to the first symbol and smaller than or equal to the second
   symbol.
_
-
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: Fw: [Bugme-new] [Bug 4334] New: kernel support for netmos 9835/9735 crippled since 2.6.9

2005-03-14 Thread Thomas Richter

Hi Andrew,
 
 I'm inclined to simply revert that change.

In case the mentioned lines do cause problems, please do not hesitate
to remove them. As the comments indicate, the patch was completely
untested as I haven't had the cards available. However, please ensure
that the parallel port remains available for the 9835/9735 in case
they are removed from the parport module. Their references should be
removed *only* from parport_pc, not from the PCI name database.

So long,
Thomas

-
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: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI breaks USB

2005-03-14 Thread Li, Shaohua
Hi,
This issue is quite interesting. We removed all specific VIA quirk
recently and apply a generic VIA quirk. But in this case, the MCH 00:0.0
is from AMD, and the ISA bridge and built-in devices are from VIA, this
means VIA quirk is useless, since it takes action only when the MCH is
from VIA. We possibly should enable VIA quirk if a VIA ISA bridge is
found instead of a VIA MCH found, but Bjorn's method seems ok.
If you want to put the patch into kernel, please also change the '
pirq_enable_irq' case.

Thanks,
Shaohua

-Original Message-
From: [EMAIL PROTECTED] [mailto:acpi-devel-
[EMAIL PROTECTED] On Behalf Of Grzegorz Kulewski
Sent: Sunday, March 13, 2005 11:15 PM
To: Bjorn Helgaas
Cc: Andrew Morton; ACPI List; lkml
Subject: Re: [ACPI] Re: Fw: Anybody? 2.6.11 (stable and -rc) ACPI
breaks
USB

On Fri, 11 Mar 2005, Bjorn Helgaas wrote:

 Can you do an lspci -vvn?  I'm looking at quirk_via_irqpic() in
 2.6.9, which is what printed this:

PCI: Via IRQ fixup for :00:07.2, from 9 to 10
PCI: Via IRQ fixup for :00:07.3, from 9 to 10

 but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
 PCI_DEVICE_ID_VIA_82C686_5, and PCI_DEVICE_ID_VIA_82C686_6.

 You have:

 :00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo
Super
South] (rev 40)
 :00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
 :00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
00 [UHCI])
 :00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a)
(prog-if
00 [UHCI])

 and we apparently ran the quirk for 07.2 and 07.3.  I wouldn't
 have thought those would have one of the above device IDs.  The
 lspci -vvn should tell us for sure.

 2.6.11 removed that quirk and runs quirk_via_bridge() for
 all VIA devices, but only sets via_interrupt_line_quirk if
 (pdev-devfn == 0), which you don't have.  So that's why
 my patch didn't do anything.

 Also two more questions:

 1. What is VIA fixup? Is it some hardware bug? Or BIOS problem? Why
is
it
 needed? On what hardware / software it is needed?

 I really don't know much about the VIA fixup.  I just noticed
 that we seem to be doing it slightly differently in 2.6.11 than
 we did in 2.6.9, and thought maybe it was related to your problem.
 Here's a changeset that has a couple pointers:

http://linux.bkbits.net:8080/linux-
2.5/cset%4041cb9d48DRV4TYe77gvstTawuZFYyQ

 2. Why this patch shrinked bzImage that much:

 -rw-r--r--  1 root root 1828186 mar 11 23:33 vmlinuz-2.6.11-cko1
 -rw-r--r--  1 root root 1828355 mar  2 20:48 vmlinuz-2.6.11-cko1.old

 I have no idea about this.  But it's only a couple hundred bytes.

 So here's another patch to try (revert the first one, then apply
this).

 = drivers/acpi/pci_irq.c 1.37 vs edited =
 --- 1.37/drivers/acpi/pci_irq.c  2005-03-01 09:57:29 -07:00
 +++ edited/drivers/acpi/pci_irq.c2005-03-11 15:13:49 -07:00
 @@ -30,6 +30,7 @@
 #include linux/module.h
 #include linux/init.h
 #include linux/types.h
 +#include linux/delay.h
 #include linux/proc_fs.h
 #include linux/spinlock.h
 #include linux/pm.h
 @@ -438,10 +439,17 @@
  }
  }

 -if (via_interrupt_line_quirk)
 -pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq 
15);
 -
  dev-irq = acpi_register_gsi(irq, edge_level, active_high_low);
 +
 +if (dev-vendor == PCI_VENDOR_ID_VIA) {
 +u8 old_irq, new_irq = dev-irq  0xf;
 +
 +pci_read_config_byte(dev, PCI_INTERRUPT_LINE, old_irq);
 +printk(KERN_INFO PREFIX Via IRQ fixup for %s, from %d 
 +to %d\n, pci_name(dev), old_irq, new_irq);
 +udelay(15);
 +pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 +}

  printk(KERN_INFO PREFIX PCI interrupt %s[%c] - GSI %u 
  (%s, %s) - IRQ %d\n,


Ok, this patch works. Here is the log:

Mar 13 17:16:17 kangur Linux version 2.6.11-cko1 ([EMAIL PROTECTED]) (gcc
version 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6))
#3
Sun Mar 13 17:10:10 CET 2005
Mar 13 17:16:17 kangur BIOS-provided physical RAM map:
Mar 13 17:16:17 kangur BIOS-e820:  - 0009fc00
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 0009fc00 - 000a
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 000f - 0010
(reserved)
Mar 13 17:16:17 kangur BIOS-e820: 0010 - 1fff
(usable)
Mar 13 17:16:17 kangur BIOS-e820: 1fff - 1fff3000
(ACPI NVS)
Mar 13 17:16:17 kangur BIOS-e820: 1fff3000 - 2000
(ACPI data)
Mar 13 17:16:17 kangur BIOS-e820:  - 0001
(reserved)
Mar 13 17:16:17 kangur 511MB LOWMEM available.
Mar 13 17:16:17 kangur On node 0 totalpages: 131056
Mar 13 17:16:17 kangur DMA zone: 4096 pages, LIFO batch:1
Mar 13 17:16:17 kangur Normal zone: 126960 pages, LIFO batch:16
Mar 13 17:16:17 kangur HighMem zone: 0 pages, LIFO 

[TTY] overrun notify issue during 5 minutes after booting

2005-03-14 Thread moreau francis
I noticed that TTY is not able to notify overrun issue
in n_tty_receive_overrun. Actually it's because of
time_before macro which tests tty-overrun_time 
(equals to 0) against jiffies - HZ (something very
big
after booting).
I guess a simple way to solve it, is to initialize
tty-overrun_time to jiffies. But it won't work if
an overrun appear after a very long while

Thanks

Francis






Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.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: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

2005-03-14 Thread Steven Rostedt


On Mon, 14 Mar 2005, Steven Rostedt wrote:


   I'll test this with PREEMPT_DESKTOP and data=ordered also and see how it
   goes.
 
  Does not seem to work at all with the above settings.  It seemed OK
  until I started X.  Then every time I launched an xterm it would
  disappear as soon as I typed anything.  I could not switch consoles to
  see the Oops.
 

 Hi Lee,

 I just compiled PREEMPT_DESKTOP and mounted root (only disk filesystem on
 my test machine) as data=ordered.  I had no problem getting to X, starting
 an xterm and running a make. Actually it was a gnome-term since I didn't
 have xterm. But then I su to root, apt-get xterm, ran xterm, and did a
 make there with no problems.

 Did you patch this against 39-02 or -40-X?

 I haven't had time to upgrade to 40 yet.  Maybe, I'll work on that today.


I just downloaded -40 and applied my patch, compiled it with
PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
I'm getting the following...

BUG: Unable to handle kernel NULL pointer dereference at virtual address

 printing eip:
c0213438
*pde = 
Oops:  [#1]
Modules linked in: ipv6 af_packet tsdev mousedev evdev floppy psmouse
pcspkr snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd soundcore snd_page_alloc shpchp pci_hotplug ehci_hcd
intel_agp agpgart uhci_hcd usbcore e100 mii ide_cd cdrom unix
CPU:0
EIP:0060:[c0213438]Not tainted VLI
EFLAGS: 00010286   (2.6.11-RT-V0.7.40-00)
EIP is at vt_ioctl+0x18/0x1ab0
eax:    ebx: 5603   ecx: 5603   edx: cb6c8780
esi: c0213420   edi: cc956000   ebp: cb613f18   esp: cb613e48
ds: 007b   es: 007b   ss: 0068   preempt: 
Process XFree86 (pid: 4713, threadinfo=cb612000 task=cb5e0a40)
Stack: cb5e0b90 cb612000 cb5e0a40 c034494c cb5e0a40 0246 cb613e7c
c0117217
   c0344954 0006 0001   cb613ebc ce0cce24
c13e1800
   cf1279b8   cb613ed4 c01707f1 cf1279b8 0007

Call Trace:
 [c0103cdf] show_stack+0x7f/0xa0 (28)
 [c0103e95] show_registers+0x165/0x1d0 (56)
 [c0104088] die+0xc8/0x150 (64)
 [c0115376] do_page_fault+0x356/0x6c4 (216)
 [c0103973] error_code+0x2b/0x30 (268)
 [c020e91b] tty_ioctl+0x34b/0x490 (52)
 [c016837f] do_ioctl+0x4f/0x70 (32)
 [c0168582] vfs_ioctl+0x62/0x1d0 (40)
 [c0168751] sys_ioctl+0x61/0x90 (40)
 [c0102ec3] syscall_call+0x7/0xb (-8124)
Code: ff ff 8d 05 88 4d 34 c0 e8 f6 60 0a 00 e9 3a ff ff ff 90 55 89 e5 57
56 53 81 ec c4 00 00 00 8b 7d 08 8b 5d 10 8b 87 7c 09 00 00 8b 30 89 34
24 8b 04 b5 e0 b7 3c c0 89 45 8c e8 a4 6a 00 00 85


I'll see if this happens without the patch, and if so, then I'll look into
this further.

Thanks,

-- Steve

-
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] PPC64 delete unused file iSeries_fixup.h

2005-03-14 Thread Paul Mackerras
This patch is from Domen Puncer [EMAIL PROTECTED].

Remove nowhere referenced file. (egrep filename\. didn't find anything)

Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Stephen Rothwell [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

diff -L include/asm-ppc64/iSeries/iSeries_fixup.h -puN 
include/asm-ppc64/iSeries/iSeries_fixup.h~remove_file-include_asm_ppc64_iSeries_iSeries_fixup.h
 /dev/null
--- kj/include/asm-ppc64/iSeries/iSeries_fixup.h
+++ /dev/null   2005-03-02 11:34:59.0 +0100
@@ -1,25 +0,0 @@
-
-#ifndef__ISERIES_FIXUP_H__
-#define__ISERIES_FIXUP_H__
-#include linux/pci.h
-
-#ifdef __cplusplus
-extern C {
-#endif
-
-void iSeries_fixup (void);
-void iSeries_fixup_bus (struct pci_bus*);
-unsigned int iSeries_scan_slot (struct pci_dev*, u16, u8, u8);
-
-
-/* Need to store information related to the PHB bucc and make it accessible to 
the hose */
-struct iSeries_hose_arch_data {
-   u32 hvBusNumber;
-};
-
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif /* __ISERIES_FIXUP_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/


[PATCH] PPC64 delete unused file no_initrd.c

2005-03-14 Thread Paul Mackerras
This patch is from Domen Puncer [EMAIL PROTECTED].

Remove nowhere referenced file. (egrep filename\. didn't find anything)

Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]

diff -L arch/ppc64/boot/no_initrd.c -puN 
arch/ppc64/boot/no_initrd.c~remove_file-arch_ppc64_boot_no_initrd.c /dev/null
--- kj/arch/ppc64/boot/no_initrd.c
+++ /dev/null   2005-03-02 11:34:59.0 +0100
@@ -1,2 +0,0 @@
-char initrd_data[1];
-int initrd_len = 0;
-
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][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Rene Scharfe
Albert Cahalan wrote:
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes' 
/proc directories?  Isn't it similar to being able to chmod their home 
directories?  They own both objects, after all (both conceptually and as 
attributed in the filesystem).

Note: I'm the procps (ps, top, w, etc.) maintainer.
Probably I'd have to make /bin/ps run setuid root
to deal with this. (minor changes needed) The same
goes for /usr/bin/top, which I know is currently
unsafe and difficult to fix.
Let's not go there, OK?
I have to admit to not having done any real testing with those 
utilities.  My excuse is this isn't such a new feature, Openwall had 
something similar for at least four years now and GrSecurity contains 
yet another flavour of it.  Openwall also provides one patch for 
procps-2.0.6, so I figured that problem (whatever their patch is about) 
got fixed in later versions.

Why do ps and top need to be setuid root to deal with a resticted /proc? 
   What information in /proc/pid needs to be available to any and all 
users?

If you restricted this new ability to root, then I'd
have much less of an objection. (not that I'd like it)
How about a boot parameter or sysctl to enable the chmod'ability of 
/proc/pid, defaulting to off?  But I'd like to resolve your more 
general objections above first, if possible. :)

Thanks for your comments,
Rene
-
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: IA32 (2.6.11 - 2005-03-12.16.00) - 56 New warnings

2005-03-14 Thread Gerd Knorr
  struct dvb_pll_desc {
[ ... ]
  struct {
[ ... ]
  } entries[];
  };
  
   while 2.6.11-mm3 changed it into entries[0].
 
 The original code failed to compile with gcc-2.95.4, so I stuck the [0] in
 there, then was vaguely surprised when no warnings came out.  Seems that
 later compilers _do_ warn.
 
 I guess we could put a 9 in there.

Yep, that should do, I think that is enougth for all existing
entries ...

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)
-
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: [TTY] overrun notify issue during 5 minutes after booting

2005-03-14 Thread Andrew Morton
moreau francis [EMAIL PROTECTED] wrote:

 I noticed that TTY is not able to notify overrun issue
  in n_tty_receive_overrun. Actually it's because of
  time_before macro which tests tty-overrun_time 
  (equals to 0) against jiffies - HZ (something very
  big
  after booting).
  I guess a simple way to solve it, is to initialize
  tty-overrun_time to jiffies. But it won't work if
  an overrun appear after a very long while

How does this look?


--- 25/drivers/char/tty_io.c~tty-overrun-time-fix   2005-03-14 
01:45:43.0 -0800
+++ 25-akpm/drivers/char/tty_io.c   2005-03-14 01:46:02.0 -0800
@@ -2632,6 +2632,7 @@ static void initialize_tty_struct(struct
tty-magic = TTY_MAGIC;
tty_ldisc_assign(tty, tty_ldisc_get(N_TTY));
tty-pgrp = -1;
+   tty-overrun_time = jiffies;
tty-flip.char_buf_ptr = tty-flip.char_buf;
tty-flip.flag_buf_ptr = tty-flip.flag_buf;
INIT_WORK(tty-flip.work, flush_to_ldisc, tty);
diff -puN drivers/char/n_tty.c~tty-overrun-time-fix drivers/char/n_tty.c
--- 25/drivers/char/n_tty.c~tty-overrun-time-fix2005-03-14 
01:49:25.0 -0800
+++ 25-akpm/drivers/char/n_tty.c2005-03-14 01:50:10.0 -0800
@@ -606,9 +606,11 @@ static inline void n_tty_receive_overrun
char buf[64];
 
tty-num_overrun++;
-   if (time_before(tty-overrun_time, jiffies - HZ)) {
-   printk(KERN_WARNING %s: %d input overrun(s)\n, tty_name(tty, 
buf),
-  tty-num_overrun);
+   if (time_before(tty-overrun_time, jiffies - HZ) ||
+   time_after(tty-overrun_time, jiffies)) {
+   printk(KERN_WARNING %s: %d input overrun(s)\n,
+   tty_name(tty, buf),
+   tty-num_overrun);
tty-overrun_time = jiffies;
tty-num_overrun = 0;
}
_

-
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/


BK-kernel-tools/shortlog update

2005-03-14 Thread Matthias Andree
Hello Linus,

you can either use bk receive to patch with this mail,
or you can
Pull from: bk://krusty.dt.e-technik.uni-dortmund.de/BK-kernel-tools
or in cases of dire need, you can apply the patch below.

BK parent: http://bktools.bkbits.net/bktools

Patch description:
[EMAIL PROTECTED], 2005-03-14 08:17:19+01:00, [EMAIL PROTECTED]
  shortlog: add 22 new addresses; re-sort

Matthias



# DIFFSTAT #
 shortlog |   24 +++-
 1 files changed, 23 insertions(+), 1 deletion(-)

# GNUPATCH #
--- 1.255/shortlog  2005-03-11 11:18:49 +01:00
+++ 1.256/shortlog  2005-03-14 08:16:36 +01:00
@@ -235,8 +235,8 @@
 'akpm:osdl.org' = 'Andrew Morton', # guessed
 'akpm:reardensteel.com' = 'Andrew Morton',
 'akpm:zip.com.au' = 'Andrew Morton',
-'akropel:rochester.rr.com' = 'Adam Kropelin', # guessed
 'akropel1:rochester.rr.com' = 'Adam Kropelin', # lbdb
+'akropel:rochester.rr.com' = 'Adam Kropelin', # guessed
 'al.fracchetti:tin.it' = 'Alessandro Fracchetti',
 'alain.knaff:lll.lu' = 'Alain Knaff',
 'alain:linux.lu' = 'Alain Knaff',
@@ -329,6 +329,7 @@
 'aoki:sdl.hitachi.co.jp' = 'Hideo Aoki',
 'aoliva:redhat.com' = 'Alexandre Oliva',
 'ap:cipherica.com' = 'Alex Pankratov',
+'apatard:mandrakesoft.com' = 'Arnaud Patard',
 'apm:brigitte.dna.fi' = 'Antti P. Miettinen',
 'apolkosnik:directvinternet.com' = 'Adam Polkosnik',
 'appro:fy.chalmers.se' = 'Andy Polyakov',
@@ -337,6 +338,7 @@
 'arashi:yomerashi.yi.org' = 'Matt Reppert',
 'arekm:pld-linux.org' = 'Arkadiusz Miskiewicz', # lbdb
 'arief_m_utama:telkomsel.co.id' = 'Arief Mulya Utama',
+'ariel:blueslice.com' = 'Ariel Rosenblatt',
 'aris:cathedrallabs.org' = 'Aristeu Sergio Rozanski Filho',
 'arjan:fenrus.demon.nl' = 'Arjan van de Ven',
 'arjan:infradead.org' = 'Arjan van de Ven',
@@ -475,6 +477,7 @@
 'braam:clusterfs.com' = 'Peter Braam',
 'brad:wasp.net.au' = 'Brad Campbell',
 'brad_mssw:gentoo.org' = 'Brad House',
+'bram.verweij:wanadoo.nl' = 'Bram Verweij',
 'bram:sara.nl' = 'Bram Stolk',
 'braunu:de.ibm.com' = 'Ursula Braun-Krahl',
 'brazilnut:us.ibm.com' = 'Don Fry',
@@ -580,6 +583,7 @@
 'cip307:cip.physik.uni-wuerzburg.de' = 'Jochen Karrer', # from shortlog
 'ckoerner:sysgo.com' = 'Christian Koerner',
 'ckulesa:as.arizona.edu' = 'Craig Kulesa',
+'cl81:gmx.net' = 'Christian Ludwig',
 'clameter:sgi.com' = 'Christoph Lameter',
 'clear.zhang:uli.com.tw' = 'Clear Zhang',
 'clemens-dated-1061728015.bf63:endorphin.org' = 'Fruhwirth Clemens',
@@ -801,6 +805,7 @@
 'ducrot:poupinou.org' = 'Bruno Ducrot',
 'duncan.sands:math.u-psud.fr' = 'Duncan Sands',
 'duncan:sun.com' = 'Duncan Laurie',
+'duraid:octopus.com.au' = 'Duraid Madina',
 'duwe:suse.de' = 'Torsten Duwe',
 'dvhltc:us.ibm.com' = 'Darren Hart',
 'dvrabel:arcom.co.uk' = 'David Vrabel',
@@ -871,6 +876,7 @@
 'eric.lemoine:gmail.com' = 'Eric Lemoine',
 'eric.moore:lsil.com' = 'Eric Moore',
 'eric.piel:bull.net' = 'Eric Piel',
+'eric.piel:lifl.fr' = 'Eric Piel',
 'eric.valette:free.fr' = 'Eric Valette',
 'eric:lammerts.org' = 'Eric Lammerts',
 'eric:yhbt.net' = 'Eric Wong',
@@ -986,6 +992,7 @@
 'ghoz:sympatico.ca' = 'Ghozlane Toumi',
 'gibbs:overdrive.btc.adaptec.com' = 'Justin T. Gibbs',
 'gibbs:scsiguy.com' = 'Justin T. Gibbs',
+'gijoe:poczta.onet.pl' = 'Daniel Johnson',
 'gilbertd:treblig.org' = 'Dr. David Alan Gilbert',
 'giorgio:org.rmk.(none)' = 'Giorgio Padrin',
 'giri:lmc.cs.sunysb.edu' = 'Giridhar Pemmasani',
@@ -1049,6 +1056,7 @@
 'hadi:znyx.com' = 'Jamal Hadi Salim', # typo
 'hadi:zynx.com' = 'Jamal Hadi Salim',
 'hager:cs.umu.se' = 'Peter Hagervall',
+'hal:realmsys.com' = 'Hal Tolley',
 'hall:vdata.com' = 'Jeff Hall',
 'hallyn:cs.wm.edu' = 'Serge Hallyn',
 'halr:voltaire.com' = 'Hal Rosenstock',
@@ -1207,6 +1215,7 @@
 'jbarnes:sgi.com' = 'Jesse Barnes',
 'jbaron:redhat.com' = 'Jason Baron',
 'jbglaw:lug-owl.de' = 'Jan-Benedict Glaw',
+'jbj1:ultraemail.net' = 'Jens B. Jorgensen',
 'jblack:linuxguru.net' = 'James Blackwell',
 'jbm:joshisanerd.com' = 'Josh Myer',
 'jbourne:hardrock.org' = 'James Bourne',
@@ -1296,6 +1305,7 @@
 'jim:jtan.com' = 'Jim Paris',
 'jimix:watson.ibm.com' = 'Jimi Xenidis',
 'jk:ozlabs.org' = 'Jeremy Kerr',
+'jkacur:rogers.com' = 'John Kacur',
 'jkenisto:us.ibm.com' = 'James Keniston',
 'jkluebs:com.rmk.(none)' = 'John K. Luebs',
 'jkmaline:cc.hut.fi' = 'Jouni Malinen',
@@ -1376,6 +1386,7 @@
 'jsimmons:kozmo.(none)' = 'James Simmons',
 'jsimmons:maxwell.earthlink.net' = 'James Simmons',
 'jsimmons:transvirtual.com' = 'James Simmons',
+'jsimmons:www.infradead.org' = 'James Simmons',
 'jsm:fc.hp.com' = 'John S. Marvin',
 'jsm:udlkern.fc.hp.com' = 'John S. Marvin',
 'jstultz:us.ibm.com' = 'John Stultz',
@@ -1592,6 +1603,7 @@
 'linux:de.rmk.(none)' = 'Dominik Brodowski',
 'linux:de.rmk.(none2)' = 'Sebastian Henschel',
 'linux:dominikbrodowski.de' = 'Dominik Brodowski',
+'linux:dominikbrodowski.net' = 'Dominik Brodowski',
 'linux:hazard.jcu.cz' = 'Jan Marek',
 'linux:kodeaffe.de' = 

Re: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-14 Thread Andrew Morton
Greg Stark [EMAIL PROTECTED] wrote:

   Greg Stark [EMAIL PROTECTED] writes:
   
Andrew Morton [EMAIL PROTECTED] writes:

 Are you able to narrow it down to something more fine grained than 
 between
 2.6.6 and 2.6.9-rc1?

Er, I suppose I would have to build some more kernels. Ugh. Is there a 
 good
place to start or do I have to just do a binary search?
 
  Well, I built a slew of kernels but found it on the first reboot.
 
  2.6.7 doesn't work.
 
  I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load 
 them.
 

Herbert tells me that this might be fixed in 2.6.11.  Did you try that?
-
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: fsck error on flashcard with ext2 filesystem

2005-03-14 Thread Jan Kara
  Hello,

   Although sync doesnt seem to make any difference to fsck output, 
 blockdev --flushbufs fixes the issue. 
 
 Still wondering why the flushing of buffer behavior is different on a 
 system with normal harddisk (Redhat 7.2 with 2.4.26 kernel ) as compared
  to a system with flashcard (CoreLinux with 2.4.26 kernel) although the 
 system parameters/daemons are the same. I dont have to do sync or 
 blockdev --flushbufs on standard system. Any ideas?
  Hmm, are the kernels really vanilla kernels without any patches?
Anyway the problem was that on the system with flashcard old data were
still kept in the cache for userspace (userspace uses cache independent from
the one filesystem uses), so it could be anything starting by different
amount of memory and ending at a different timing/command sequence
whatever...

 I was using fsck with -n option which doesnt executes the command, just
 shows what would be done. I thought it would be harmless.
  Ok, that won't harm the filesystem but you can still see errors which
are not on the filesystem (because of the cache issues).

 -Original Message-
 From: Jan Kara [mailto:[EMAIL PROTECTED]
 Sent: Friday, March 11, 2005 6:37 AM
 To: Santosh Gupta
 Cc: linux-kernel@vger.kernel.org
 Subject: Re: fsck error on flashcard with ext2 filesystem
 
 
   Hello,
 
   just a reminder for the next time - please keep the lines length under 80
 characters.
 
  Detailed Description
  -
  I am using Core Linux system on flashcard. Its another minimal linux
  distribution. Root filesystem is cramfs and a rw partition on flash is
  ext2. The system is always shutdown properly and initial fsck upon
  bootup shows no error. But if I delete a file on flash card and run
  fsck, it gives error in fsck. On umount and mounting again (or
  reboot), fsck shows no problem. Issuing sync command doesnt make any
  difference.
  Why is the disk not getting updated with filesystem metadata even
  after I wait for so long?
   Hmm, it may be a cache aliasing issue (anyway doing fsck on a mounted
 filesystem is asking for a trouble and basically nobody promisses any
 result). But you may try doing something like:
   sync; blockdev --flushbufs
 
 before a fsck.
 

Honza

-- 
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
-
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] x86: fix ESP corruption CPU bug

2005-03-14 Thread Andi Kleen
Stas Sergeev [EMAIL PROTECTED] writes:

 Another way of saying the same thing: I absolutely hate seeing
 patches that fix some theoretical issue that no Linux apps will ever
 care about.
 No, it is not theoretical, but it is mainly
 about a DOS games and an MS linker, as for
 me. The things I'd like to get working, but
 the ones you may not care too much about:)
 The particular game I want to get working,
 is Master of Orion 2 for DOS.

How about you just run it in dosbox instead of dosemu ?

-Andi
-
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] fix mprotect() with len=(size_t)(-1) to return -ENOMEM

2005-03-14 Thread Gordon Jin
This patch fixes a corner case in sys_mprotect(): 

Case: len is so large that will overflow to 0 after page alignment.
E.g. len=(size_t)(-1), i.e. 0xff...ff.
Expected result: POSIX spec says it should return -ENOMEM.
Current result: len is aligned to 0, then treated the same as len=0 and
return success.

--- linux-2.6.11.3/mm/mprotect.c.orig   2005-03-14 13:40:28.0
-0800
+++ linux-2.6.11.3/mm/mprotect.c2005-03-14 13:42:41.0 -0800
@@ -232,14 +232,14 @@ sys_mprotect(unsigned long start, size_t
 
if (start  ~PAGE_MASK)
return -EINVAL;
+   if (!len)
+   return 0;
len = PAGE_ALIGN(len);
end = start + len;
-   if (end  start)
+   if (end = start)
return -ENOMEM;
if (prot  ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM))
return -EINVAL;
-   if (end == start)
-   return 0;
/*
 * Does the application expect PROT_READ to imply PROT_EXEC:
 */


-
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.4.29 'make dep' error

2005-03-14 Thread DervishD
Hi all :)

I don't know if I've had this error previously, I noticed it this
morning when recompiling the kernel *I already use*. When doing 'make
dep' I had this:

make[1]: Leaving directory `/usr/kernel'
scripts/mkdep -- `find /usr/kernel/include/asm /usr/kernel/include/linux
  /usr/kernel/include/scsi /usr/kernel/include/net 
/usr/kernel/include/math-emu
  \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h !
  -name modversions.h -print`  .hdepend
find: /usr/kernel/include/asm: Too many levels of symbolic links
scripts/mkdep -- init/*.c  .depend

I've break the long line invoking the 'scripts/mkdep' binary so
it's easier to read. I don't know why the heck 'find' fails with
ELOOP :?? Just a simple 'find /usr/kernel/include/asm -follow' causes
'find' to issue a open call that fails with ELOOP. I'm using version
4.2.18 (I updated recently my findutils) and version 4.2.15 doesn't
show the problem.

I just wanted to warn everybody on the list about this problem.
I'm going to write to findutils people to report the bug.

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.dervishd.net  http://www.pleyades.net/
It's my PC and I'll cry if I want to...
-
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: Fw: [Bugme-new] [Bug 4334] New: kernel support for netmos 9835/9735 crippled since 2.6.9

2005-03-14 Thread Andrew Morton
Thomas Richter [EMAIL PROTECTED] wrote:

 
 Hi Andrew,
  
  I'm inclined to simply revert that change.
 
 In case the mentioned lines do cause problems, please do not hesitate
 to remove them. As the comments indicate, the patch was completely
 untested as I haven't had the cards available. However, please ensure
 that the parallel port remains available for the 9835/9735 in case
 they are removed from the parport module. Their references should be
 removed *only* from parport_pc, not from the PCI name database.
 

OK.  Like this?

Steven, do you agree?

diff -puN drivers/parport/parport_pc.c~parport_pc-revert-netmos-patch 
drivers/parport/parport_pc.c
--- 25/drivers/parport/parport_pc.c~parport_pc-revert-netmos-patch  
2005-03-14 01:55:52.0 -0800
+++ 25-akpm/drivers/parport/parport_pc.c2005-03-14 01:59:32.0 
-0800
@@ -2738,8 +2738,6 @@ enum parport_pc_pci_cards {
netmos_9855,
netmos_9735,
netmos_9835,
-   netmos_9755,
-   netmos_9715
 };
 
 
@@ -2813,10 +2811,8 @@ static struct parport_pc_pci {
/* netmos_9805 */   { 1, { { 0, -1 }, } }, /* untested */
/* netmos_9815 */   { 2, { { 0, -1 }, { 2, -1 }, } }, /* 
untested */
/* netmos_9855 */   { 2, { { 0, -1 }, { 2, -1 }, } }, /* 
untested */
-   /* netmos_9735 */   { 1, { { 2, 3 }, } },  /* untested */
-   /* netmos_9835 */   { 1, { { 2, 3 }, } },  /* untested */
-/* netmos_9755 */   { 2, { { 0, 1 }, { 2, 3 },} }, /* 
untested */
-/* netmos_9715 */   { 2, { { 0, 1 }, { 2, 3 },} }, /* 
untested */
+   /* netmos_9735 */   { 1, { { 2, 3 }, } },
+   /* netmos_9835 */   { 1, { { 2, 3 }, } },
 };
 
 static struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2899,10 +2895,6 @@ static struct pci_device_id parport_pc_p
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9735 },
{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9835 },
-   { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9755,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9755 },
-   { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9715,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9715 },
{ 0, } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci,parport_pc_pci_tbl);
diff -puN include/linux/pci_ids.h~parport_pc-revert-netmos-patch 
include/linux/pci_ids.h
--- 25/include/linux/pci_ids.h~parport_pc-revert-netmos-patch   2005-03-14 
01:55:52.0 -0800
+++ 25-akpm/include/linux/pci_ids.h 2005-03-14 01:55:52.0 -0800
@@ -2530,8 +2530,6 @@
 #define PCI_DEVICE_ID_NETMOS_9815  0x9815
 #define PCI_DEVICE_ID_NETMOS_9835  0x9835
 #define PCI_DEVICE_ID_NETMOS_9855  0x9855
-#define PCI_DEVICE_ID_NETMOS_9755  0x9755
-#define PCI_DEVICE_ID_NETMOS_9715  0x9715
 
 #define PCI_SUBVENDOR_ID_EXSYS 0xd84d
 #define PCI_SUBDEVICE_ID_EXSYS_40140x4014
_

-
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.11-rc3-V0.7.38-01

2005-03-14 Thread Steven Rostedt


On Mon, 14 Mar 2005, Steven Rostedt wrote:

 I just downloaded -40 and applied my patch, compiled it with
 PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
 I'm getting the following...

 BUG: Unable to handle kernel NULL pointer dereference at virtual address
 
  printing eip:
 c0213438
 *pde = 

[snip]



 I'll see if this happens without the patch, and if so, then I'll look into
 this further.


Well, I took out my patch and this bug didn't happen, so I guess it's may
fault!  OK, I'll dig into it further.

-- Steve

-
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] fix mprotect() with len=(size_t)(-1) to return -ENOMEM

2005-03-14 Thread Arjan van de Ven
On Mon, 2005-03-14 at 17:55 +0800, Gordon Jin wrote:
 This patch fixes a corner case in sys_mprotect(): 
 
 Case: len is so large that will overflow to 0 after page alignment.

shouldn't we just fix the alignment code instead that the overflow case
doesn't align to 0???
that sounds really odd.


-
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] No-exec support for ppc64

2005-03-14 Thread Paul Mackerras
Jake Moilanen writes:

 diff -puN fs/binfmt_elf.c~nx-user-ppc64 fs/binfmt_elf.c
 --- linux-2.6-bk/fs/binfmt_elf.c~nx-user-ppc642005-03-08 16:08:54 
 -06:00
 +++ linux-2.6-bk-moilanen/fs/binfmt_elf.c 2005-03-08 16:08:54 -06:00
 @@ -99,6 +99,8 @@ static int set_brk(unsigned long start, 
   up_write(current-mm-mmap_sem);
   if (BAD_ADDR(addr))
   return addr;
 +
 + sys_mprotect(start, end-start, PROT_READ|PROT_WRITE|PROT_EXEC);

I don't think I can push that upstream.  What happens if you leave
that out?

More generally, we are making a user-visible change, even for programs
that aren't marked as having non-executable stack or heap, because we
are now enforcing that the program can't execute from mappings that
don't have PROT_EXEC.  Perhaps we should enforce the requirement for
execute permission only on those programs that indicate somehow that
they can handle it?

Paul.
-
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: Serious problems with HFS+

2005-03-14 Thread Roman Zippel
Hi,

On Sun, 13 Mar 2005, Matt Mackall wrote:

 I've noticed a few problems with HFS+ support in recent kernels on
 another user's machine running Ubuntu (Warty) running
 2.6.8.1-3-powerpc. I'm not in a position to extensively test or fix
 either of these problem because of the fs tools situation so I'm just
 passing this on.
 
 First, it reports inappropriate blocks to stat(2). It uses 4096 byte
 blocks rather than 512 byte blocks which stat callers are expecting.
 This seriously confuses du(1) (and me, for a bit). Looks like it may
 be forgetting to set s_blocksize_bits.

This should be fixed since 2.6.10.

 Second, if an HFS+ filesystem mounted via Firewire or USB becomes
 detached, the filesystem appears to continue working just fine. I can
 find on the entire tree, despite memory pressure. I can even create
 new files that continue to appear in directory listings! Writes to
 such files succeed (they're async, of course) and the typical app is
 none the wiser. It's only when apps attempt to read later that they
 encounter problems. It turns out that various apps including scp
 ignore IO errors on read and silently copy zero-filled files to the
 destination. So I got this report as why aren't the pictures I took
 off my camera visible on my website?

HFS+ metadata is also in the page cache, so as long as everything is 
cached, HFS+ won't notice a problem.

 This is obviously a really nasty failure mode. At the very least, open
 of new files should fail with -EIO. Preferably the fs should force a
 read-only remount on IO errors. Given that the vast majority of HFS+
 filesystems Linux is likely to be used with are on hotpluggable media,
 I think this FS should be marked EXPERIMENTAL until such integrity
 problems are addressed.

Currently nobody tells fs about such events, so even if I check for 
write errors, it can still take a while until the error is detected.
I acknowledge that this is a problem, but I don't think it's a HFS+ 
specific problem, there is currently no standard procedure for fs what to 
do in such situations, so I didn't implement anything.
It would be nice if the fs would be tould about plug/unplug events, e.g. 
HFS+ could check the mount count to see if it was connected to a different 
host in the meantime and react appropriately.

 Having the whole directory tree seemingly pinned in memory is probably
 something that wants addressing as well.

This actually might be a real HFS+ problem :), I have to look into it.

bye, Roman
-
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: [MC] [CHECKER] Need help on mmap on FUSE (linux user-land file system)

2005-03-14 Thread Miklos Szeredi
  Forget to mention, we are checking linux 2.6.  It appears to us
  that mmap doesnt' work for FUSE in linux 2.6.
 
 IIRC, the reason mmap doesn't work on FUSE is because when it
 dirties pages they cannot be flushed reliably, because writing them
 out involves calling a userspace process which may allocate RAM,
 etc.

Yes.  To be precise this only affects writable shared mmap(), which is
not used by the great majority of applications.  Any other kind of
memory mapping should work OK.

Thanks,
Miklos
-
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 4/5] audit mips fix

2005-03-14 Thread Ralf Baechle
On Fri, Mar 11, 2005 at 09:58:39AM +0900, Yoichi Yuasa wrote:

   Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
   Signed-off-by: Andrew Morton [EMAIL PROTECTED]
  
   @@ -307,7 +308,7 @@ asmlinkage void do_syscall_trace(struct 
{
 if (unlikely(current-audit_context)) {
 if (!entryexit)
   - audit_syscall_entry(current, regs-orig_eax,
   + audit_syscall_entry(current, regs-regs[2],
  
  Wrong.  regs[2] can will contain the syscall return value and can be
  modified by ptrace also.
 
 Thank you for your comment,
 I consider a good way based on your comment. 
 
 Do you already have a good idea?

Basically do what x86 did, keep a copy of the the original regs[2] around.
The only potencial problem with this approach is debuggers might be
affected so I want to look into that first.

  Ralf
-
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] unexport kmap_{pte,port} on !ppc

2005-03-14 Thread Ralf Baechle
On Fri, Mar 11, 2005 at 07:16:45PM +0100, Adrian Bunk wrote:

 I haven't found any modular usage of kmap_{pte,port} on !ppc in the 
 kernel.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 ---
 
 This patch was already sent on:
 - 21 Jan 2005
 
  arch/i386/mm/init.c  |3 ---
  arch/mips/mm/init.c  |3 ---

Looks good.

  Ralf
-
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/


mousekeyboard with 2.6.10+

2005-03-14 Thread Michael Tokarev
I noticied a weird problem with input subsystem (mostly
mouse) which happens on my boxes with 2.6.10 and 2.6.11+
kernels (up to current 2.6.11.3), which didn't happen with
earlier kernels.
First issue is that psmouse module takes about 10 sec to
load (to detect the mouse), which was done instantly with
older kernels.  Not a very big problem ofcourse, but looks
like it is indicating some more deep problem.
2.6.10 almost works, but sometimes, the whole input
subsystem just hungs, ie, both keyboard and mouse
just stops working.  Plugging in USB keyboard and
loading usbhid module solves the problem - both
keyboards and the mouse works after that, and I
didn't yet notice the problem repeats after usbhid
and usb keyboard is loaded.  I wasn't able to
determine when the problem occurs, for me it seems
it hangs at some random point - sometimes after
5 minutes after boot, sometimes after a hour or
so.
And 2.6.11 is almost screwed up.  I managed to
get mouse working with it only 2 or 3 times (all
after cold reboot).  It also takes about 10 sec
to load psmouse module (2.6.10 is a  bit faster),
but the mouse does just not work.  Sometimes,
it detects my mouse as Generic ps/2 mouse
(it is  Generic Wheel mouse usually).  More,
quite often, after re-loading psmouse module
the keyboard stops working as well.
I played with i8042.noacpi parameter but it has
no visible effect (incl. the dmesg output).
The machine is some Gygabyte mobo based on VT8601
chipset with VIA C3 CPU in it (I love those fanless
system for their quiet operations).  Mouse and keyboard
(PS/2 interface) are pretty standard ones, mouse has
wheel.  All the stuff reported by the kernel looks ok
too, here's the dmesg output:
Linux version 2.6.10-i486-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Mon Feb 7 15:57:55 MSK 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 077f (usable)
 BIOS-e820: 077f - 077f3000 (ACPI NVS)
 BIOS-e820: 077f3000 - 0780 (ACPI data)
 BIOS-e820: 0780 - 0800 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
119MB LOWMEM available.
On node 0 totalpages: 30704
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 26608 pages, LIFO batch:6
  HighMem zone: 0 pages, LIFO batch:1
DMI not present.
ACPI: RSDP (v000 GBT   ) @ 0x000f7340
ACPI: RSDT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x) @ 0x077f3000
ACPI: FADT (v001 GBTAWRDACPI 0x42302e31 AWRD 0x) @ 0x077f3040
ACPI: DSDT (v001 GBTAWRDACPI 0x1000 MSFT 0x010c) @ 0x
Built 1 zonelists
Kernel command line: initrd=boot/initrd-2.6.10-i486-1 root=/dev/ram0 
BOOT_IMAGE=boot/vmlinuz-2.6.10-i486-1 
ip=192.168.1.165:192.168.1.1:192.168.1.5:255.255.255.0
No local APIC present or hardware disabled
mapped APIC to d000 (010f2000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0318000 soft=c0317000
PID hash table entries: 512 (order: 9, 8192 bytes)
Detected 910.013 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 118144k/122816k available (1235k kernel code, 4116k reserved, 653k 
data, 224k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1815.34 BogoMIPS (lpj=9076736)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 00803035 80803035  
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps:00803135 80803035  
CPU: Centaur VIA Ezra stepping 08
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 8e20)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 610k freed
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfaa80, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 11 devices
PnPBIOS: Disabled by ACPI
PCI: Using ACPI for IRQ routing
** PCI 

[BUG?] x86_64 : Can not read /dev/kmem ?

2005-03-14 Thread Eric Dumazet
Hi Andi
I tried to read /dev/kmem on x86_64 (linux-2.6.11) and got no success.
read() or pread() returns EINVAL
I tried mmap() too : mmap() calls succeed, but as soon the user process 
dereference memory, we get :

tinfo: Corrupted page table at address 2aabf800
PGD 8a983067 PUD c7e5a067 PMD 91588067 PTE 8048a025
Bad pagetable: 000d [1] SMP
CPU 0
Modules linked in: ipt_REJECT
Pid: 10892, comm: tinfo Not tainted 2.6.11
RIP: 0033:[00100562] [00100562]
RSP: 002b:7790  EFLAGS: 00010217
RAX: 2aabf000 RBX: 2abbe000 RCX: 2ac8fc0c
RDX: 0001 RSI: 1000 RDI: 
RBP: 77f8 R08: 0003 R09: 8048a000
R10: 0001 R11: 0206 R12: 001005b0
R13: 0001 R14: 2adfdfe8 R15: 00100530
FS:  2abcb970() GS:804866c0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 2aabf800 CR3: 90368000 CR4: 06e0
Process tinfo (pid: 10892, threadinfo 8100901b, task 
8100c7d976c0)

RIP [00100562] RSP 7790

Thank you
Eric Dumazet

# cat tinfo.c
#define _XOPEN_SOURCE 500
#include unistd.h
#include stdio.h
#include fcntl.h
struct tcp_hashinfo {
struct tcp_ehash_bucket *__tcp_ehash;
struct tcp_bind_hashbucket *__tcp_bhash;
int __tcp_bhash_size;
int __tcp_ehash_size;
} tcp_hashinfo;
#define TCPINFO_ADDR 0x8048a000 /* tcp_hashinfo */
int main()
{
int fd = open(/dev/kmem, O_RDONLY) ;
if (pread(fd, tcp_hashinfo, sizeof(tcp_hashinfo), TCPINFO_ADDR) == -1) {
lseek(fd, TCPINFO_ADDR, 0) ;
if (read(fd, tcp_hashinfo, sizeof(tcp_hashinfo)) == -1) {
perror(Can not read /dev/kmem ?) ;
return 1 ;
}
}
printf(ehash=%p esize=%d bhash=%p bsize=%d\n,
tcp_hashinfo.__tcp_ehash,
tcp_hashinfo.__tcp_ehash_size,
tcp_hashinfo.__tcp_bhash,
tcp_hashinfo.__tcp_bhash_size) ;
return 0 ;
}
-
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] break_lock forever broken

2005-03-14 Thread Ingo Molnar

* Arjan van de Ven [EMAIL PROTECTED] wrote:

 as I said, since the cacheline just got dirtied, the write is just
 half a cycle which is so much in the noise that it really doesn't
 matter.

ok - the patch below is a small modification of Hugh's so that we clear
-break_lock unconditionally. Since this code is not inlined it ought to
have minimal icache impact too.

Ingo

--
lock-break_lock is set when a lock is contended, but cleared only in
cond_resched_lock.  Users of need_lockbreak (journal_commit_transaction,
copy_pte_range, unmap_vmas) don't necessarily use cond_resched_lock on it.

So, if the lock has been contended at some time in the past, break_lock
remains set thereafter, and the fastpath keeps dropping lock unnecessarily.
Hanging the system if you make a change like I did, forever restarting a
loop before making any progress.  And even users of cond_resched_lock may
well suffer an initial unnecessary lockbreak.

There seems to be no point at which break_lock can be cleared when
unlocking, any point being either too early or too late; but that's okay,
it's only of interest while the lock is held.  So clear it whenever the
lock is acquired - and any waiting contenders will quickly set it again.
Additional locking overhead? well, this is only when CONFIG_PREEMPT is on.

Since cond_resched_lock's spin_lock clears break_lock, no need to clear it
itself; and use need_lockbreak there too, preferring optimizer to #ifdefs.

Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]

--- 2.6.11-bk8/kernel/sched.c   2005-03-11 13:33:09.0 +
+++ linux/kernel/sched.c2005-03-11 17:46:50.0 +
@@ -3753,14 +3753,11 @@ EXPORT_SYMBOL(cond_resched);
  */
 int cond_resched_lock(spinlock_t * lock)
 {
-#if defined(CONFIG_SMP)  defined(CONFIG_PREEMPT)
-   if (lock-break_lock) {
-   lock-break_lock = 0;
+   if (need_lockbreak(lock)) {
spin_unlock(lock);
cpu_relax();
spin_lock(lock);
}
-#endif
if (need_resched()) {
_raw_spin_unlock(lock);
preempt_enable_no_resched();
--- 2.6.11-bk8/kernel/spinlock.c2005-03-02 07:38:52.0 +
+++ linux/kernel/spinlock.c 2005-03-12 22:52:41.0 +
@@ -187,6 +187,7 @@ void __lockfunc _##op##_lock(locktype##_
cpu_relax();\
preempt_disable();  \
}   \
+   (lock)-break_lock = 0; \
 }  \
\
 EXPORT_SYMBOL(_##op##_lock);   \
@@ -209,6 +211,7 @@ unsigned long __lockfunc _##op##_lock_ir
cpu_relax();\
preempt_disable();  \
}   \
+   (lock)-break_lock = 0; \
return flags;   \
 }  \
\
-
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] drivers/media Sparse fixes

2005-03-14 Thread Peter Hagervall
Removes some sparse warnings on one-bit bitfields.

Signed-off-by: Peter Hagervall [EMAIL PROTECTED]

--

 dvb/dvb-core/dvb_ca_en50221.c |6 +++---
 video/cx88/cx88.h |4 ++--
 video/msp3400.c   |4 ++--
 video/videocodec.h|   16 
 4 files changed, 15 insertions(+), 15 deletions(-)


= drivers/media/dvb/dvb-core/dvb_ca_en50221.c 1.10 vs edited =
--- 1.10/drivers/media/dvb/dvb-core/dvb_ca_en50221.c2005-03-14 00:29:37 
+01:00
+++ edited/drivers/media/dvb/dvb-core/dvb_ca_en50221.c  2005-03-14 11:40:56 
+01:00
@@ -148,13 +148,13 @@
wait_queue_head_t thread_queue;
 
/* Flag indicating when thread should exit */
-   int exit:1;
+   unsigned int exit:1;
 
/* Flag indicating if the CA device is open */
-   int open:1;
+   unsigned int open:1;
 
/* Flag indicating the thread should wake up now */
-   int wakeup:1;
+   unsigned int wakeup:1;
 
/* Delay the main thread should use */
unsigned long delay;
= drivers/media/video/msp3400.c 1.34 vs edited =
--- 1.34/drivers/media/video/msp3400.c  2005-01-25 22:50:27 +01:00
+++ edited/drivers/media/video/msp3400.c2005-03-14 11:38:24 +01:00
@@ -97,8 +97,8 @@
/* thread */
struct task_struct   *kthread;
wait_queue_head_twq;
-   int  restart:1;
-   int  watch_stereo:1;
+   unsigned int restart:1;
+   unsigned int watch_stereo:1;
 };
 
 #define HAVE_NICAM(msp)   (((msp-rev28)  0xff) != 00)
= drivers/media/video/videocodec.h 1.3 vs edited =
--- 1.3/drivers/media/video/videocodec.h2005-01-05 03:48:33 +01:00
+++ edited/drivers/media/video/videocodec.h 2005-03-14 11:37:28 +01:00
@@ -222,14 +222,14 @@
 /* = */
 
 struct vfe_polarity {
-   int vsync_pol:1;
-   int hsync_pol:1;
-   int field_pol:1;
-   int blank_pol:1;
-   int subimg_pol:1;
-   int poe_pol:1;
-   int pvalid_pol:1;
-   int vclk_pol:1;
+   unsigned int vsync_pol:1;
+   unsigned int hsync_pol:1;
+   unsigned int field_pol:1;
+   unsigned int blank_pol:1;
+   unsigned int subimg_pol:1;
+   unsigned int poe_pol:1;
+   unsigned int pvalid_pol:1;
+   unsigned int vclk_pol:1;
 };
 
 struct vfe_settings {
= drivers/media/video/cx88/cx88.h 1.8 vs edited =
--- 1.8/drivers/media/video/cx88/cx88.h 2005-03-11 21:32:23 +01:00
+++ edited/drivers/media/video/cx88/cx88.h  2005-03-14 11:39:36 +01:00
@@ -188,8 +188,8 @@
int tda9887_conf;
struct cx88_input   input[8];
struct cx88_input   radio;
-   int blackbird:1;
-   int dvb:1;
+   unsigned intblackbird:1;
+   unsigned intdvb:1;
 };
 
 struct cx88_subid {
-
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/6] PCI Express Advanced Error Reporting Driver

2005-03-14 Thread David Vrabel
long wrote:
 This patch includes PCIEAER-HOWTO.txt, which describes how the PCI
 Express Advanced Error Reporting Root driver works.

 --- linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt

Could this be placed in a sub-system subdirectory (creating one if
necessary, e.g., pci/)?  The root of Documentation/ is rather full of
random files as is.

David Vrabel
-
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] x86: fix ESP corruption CPU bug

2005-03-14 Thread Zoltan Boszormenyi
Stas Sergeev [EMAIL PROTECTED] writes:

Another way of saying the same thing: I absolutely hate seeing
patches that fix some theoretical issue that no Linux apps will ever
care about.
No, it is not theoretical, but it is mainly
about a DOS games and an MS linker, as for
me. The things I'd like to get working, but
the ones you may not care too much about:)
The particular game I want to get working,
is Master of Orion 2 for DOS.
How about you just run it in dosbox instead of dosemu ?
-Andi
Nah, don't insult a DOSemu developer. ;-) Stas is one of them...
Best regards,
Zoltn Bszrmnyi
-
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] break_lock forever broken

2005-03-14 Thread Nick Piggin
Ingo Molnar wrote:
* Arjan van de Ven [EMAIL PROTECTED] wrote:

as I said, since the cacheline just got dirtied, the write is just
half a cycle which is so much in the noise that it really doesn't
matter.

ok - the patch below is a small modification of Hugh's so that we clear
-break_lock unconditionally. Since this code is not inlined it ought to
have minimal icache impact too.
Fine by me.
-
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: A new 10GB Ethernet Driver by Chelsio Communications

2005-03-14 Thread Pekka Enberg
Some of my usual coding style comments...

On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
 diff -puN /dev/null drivers/net/chelsio/osdep.h
 --- /dev/null 2003-09-15 06:40:47.0 -0700
 +++ 25-akpm/drivers/net/chelsio/osdep.h   2005-03-11 11:13:06.0 
 -0800
 +static inline void *t1_malloc(size_t len)
 +{
 + void *m = kmalloc(len, GFP_KERNEL);
 + if (m)
 + memset(m, 0, len);
 + return m;
 +}
 +
 +static inline void t1_free(void *v, size_t len)
 +{
 + kfree(v);
 +}

Please do not introduce subsystem specific wrappers to kmalloc and kfree.

 +/*
 + * Allocates basic RX resources, consisting of memory mapped freelist Qs and 
 a
 + * response Q.
 + */
 +static int alloc_rx_resources(struct sge *sge, struct sge_params *p)
 +{
 + struct pci_dev *pdev = sge-adapter-pdev;
 + unsigned int size, i;
 +
 + for (i = 0; i  SGE_FREELQ_N; i++) {
 + struct freelQ *Q = sge-freelQ[i];
 +
 + Q-genbit = 1;
 + Q-entries_n = p-freelQ_size[i];
 + Q-dma_offset = SGE_RX_OFFSET - sge-rx_pkt_pad;
 + size = sizeof(struct freelQ_e) * Q-entries_n;
 + Q-entries = (struct freelQ_e *)
 +   pci_alloc_consistent(pdev, size, Q-dma_addr);
 + if (!Q-entries)
 + goto err_no_mem;
 + memset(Q-entries, 0, size);
 + size = sizeof(struct freelQ_ce) * Q-entries_n;
 + Q-centries = (struct freelQ_ce *) kmalloc(size, GFP_KERNEL);
 + if (!Q-centries)
 + goto err_no_mem;
 + memset(Q-centries, 0, size);

Please drop the redundant casts and use kcalloc() here and in various
other places as
well.

Also, the patch has some whitespace damage (spaces instead of tabs).

Pekka
-
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][-mm][1/2] cifs: whitespace cleanups for file.c

2005-03-14 Thread Jesper Juhl
On Mon, 14 Mar 2005, Steven French wrote:

 
  Here's the first of two patches with cleanups for fs/cifs/file.c
 The patch looks safe enough but I can not get the patch to apply (pattch
 always claims it is malformed) - whichever email clients I received it
 from probably because of wrap at 80 columns or some conversion that
 occurred in the email text of the patch, although evolution email client
 also had problems with it being to big to cut and paste (but even trying
 it in smaller chunks I could not get it to apply). If you could resend
 it as a file that would be helpful.
 
I just send it to you as an attachment in private email. I'd rather not 
resend that big a file to the lists if not needed. 

I've also put the patches online here :  

http://www.linuxtux.org/~juhl/fs_cifs_file-whitespace-cleanups-part-1.patch
http://www.linuxtux.org/~juhl/fs_cifs_file-whitespace-cleanups-part-2-and_cifs_open-rework.patch

They won't live forever at that location, but I can leave them there for a 
few weeks at least.


-- 
Jesper Juhl


-
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: cpufreq on-demand governor up_treshold?

2005-03-14 Thread Bruno Ducrot
On Mon, Mar 14, 2005 at 08:57:52AM +0100, Eric Piel wrote:
 BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot 
 available at codemonkey.org.uk. Should I worry, or is it just due to 
 some latency between your private trees and the public one?
 

This happens those days only when I upgrade the LINUX_2_4 branch
(and only because its easier for me to diff between HEAD and LINUX_2_4).

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
-
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 1/1] uml-export-getgid-for-hostfs

2005-03-14 Thread blaisorblade


Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 +
 1 files changed, 1 insertion(+)

diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 
arch/um/os-Linux/user_syms.c
--- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs  
2005-03-11 20:15:37.347405816 +0100
+++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 
20:15:43.868414472 +0100
@@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs);
 EXPORT_SYMBOL_PROTO(statfs64);
 
 EXPORT_SYMBOL_PROTO(getuid);
+EXPORT_SYMBOL_PROTO(getgid);
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.
_
-
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] (undescribed patch)

2005-03-14 Thread blaisorblade


Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/arch/um/drivers/slip_user.c |6 +-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff -puN arch/um/drivers/slip_user.c~uml-uml_net-security-fix 
arch/um/drivers/slip_user.c
--- linux-2.6.11/arch/um/drivers/slip_user.c~uml-uml_net-security-fix   
2005-03-09 12:44:10.0 +0100
+++ linux-2.6.11-paolo/arch/um/drivers/slip_user.c  2005-03-09 
12:44:10.0 +0100
@@ -108,6 +108,9 @@ static int slip_tramp(char **argv, int f
err = -EINVAL;
}
}
+
+   os_close_file(fds[0]);
+
return(err);
 }
 
@@ -128,6 +131,7 @@ static int slip_open(void *data)
sfd = os_open_file(ptsname(mfd), of_rdwr(OPENFLAGS()), 0);
if(sfd  0){
printk(Couldn't open tty for slip line, err = %d\n, -sfd);
+   os_close_file(mfd);
return(sfd);
}
if(set_up_tty(sfd)) return(-1);
@@ -175,7 +179,7 @@ static void slip_close(int fd, void *dat
 
sprintf(version_buf, %d, UML_NET_VERSION);
 
-   err = slip_tramp(argv, -1);
+   err = slip_tramp(argv, pri-slave);
 
if(err != 0)
printk(slip_tramp failed - errno = %d\n, -err);
_
-
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 1/2] uml: export getgid for hostfs

2005-03-14 Thread blaisorblade

Export this symbol which is now needed for a typo fix (getuid() - getgid()).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 +
 1 files changed, 1 insertion(+)

diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 
arch/um/os-Linux/user_syms.c
--- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs  
2005-03-11 20:16:17.061368376 +0100
+++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 
20:16:17.065367768 +0100
@@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs);
 EXPORT_SYMBOL_PROTO(statfs64);
 
 EXPORT_SYMBOL_PROTO(getuid);
+EXPORT_SYMBOL_PROTO(getgid);
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.
_
-
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] uml: cope with uml_net security fix

2005-03-14 Thread blaisorblade

Pass the interface to close as an fd besides that by name... passing it by
name does not work with newer uml_net because that allows to ifconfig down
arbitrary interfaces, while if you have an open fd to the SLIP interface it
means you have full access to it (and thus can close it). Passing only by fd
does not work with older utilities, so we do both things (which does not
hurt).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/arch/um/drivers/slip_user.c |6 +-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff -puN arch/um/drivers/slip_user.c~uml-uml_net-security-fix 
arch/um/drivers/slip_user.c
--- linux-2.6.11/arch/um/drivers/slip_user.c~uml-uml_net-security-fix   
2005-03-11 20:33:21.367650152 +0100
+++ linux-2.6.11-paolo/arch/um/drivers/slip_user.c  2005-03-11 
20:33:21.370649696 +0100
@@ -108,6 +108,9 @@ static int slip_tramp(char **argv, int f
err = -EINVAL;
}
}
+
+   os_close_file(fds[0]);
+
return(err);
 }
 
@@ -128,6 +131,7 @@ static int slip_open(void *data)
sfd = os_open_file(ptsname(mfd), of_rdwr(OPENFLAGS()), 0);
if(sfd  0){
printk(Couldn't open tty for slip line, err = %d\n, -sfd);
+   os_close_file(mfd);
return(sfd);
}
if(set_up_tty(sfd)) return(-1);
@@ -175,7 +179,7 @@ static void slip_close(int fd, void *dat
 
sprintf(version_buf, %d, UML_NET_VERSION);
 
-   err = slip_tramp(argv, -1);
+   err = slip_tramp(argv, pri-slave);
 
if(err != 0)
printk(slip_tramp failed - errno = %d\n, -err);
_
-
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: A new 10GB Ethernet Driver by Chelsio Communications

2005-03-14 Thread Pekka Enberg
Hi,

Few more coding style comments.

On Fri, 11 Mar 2005 11:21:32 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
 diff -puN /dev/null drivers/net/chelsio/cxgb2.c
 --- /dev/null 2003-09-15 06:40:47.0 -0700
 +++ 25-akpm/drivers/net/chelsio/cxgb2.c   2005-03-11 11:13:06.0 
 -0800
 @@ -0,0 +1,1284 @@
 +#ifndef HAVE_FREE_NETDEV
 +#define free_netdev(dev) kfree(dev)
 +#endif

Please drop this wrapper.

 + printk(KERN_INFO %s: %s (rev %d), %s %dMHz/%d-bit\n, adapter-name,
 +bi-desc, adapter-params.chip_revision,
 +adapter-params.pci.is_pcix ? PCIX : PCI,
 +adapter-params.pci.speed, adapter-params.pci.width);
 + return 0;
 +
 + out_release_adapter_res:
 + t1_free_sw_modules(adapter);
 + out_free_dev:
 + if (adapter) {
 + if (adapter-tdev)
 + kfree(adapter-tdev);

kfree() handles null pointers so please drop the redundant check.

 diff -puN /dev/null drivers/net/chelsio/gmac.h
 --- /dev/null 2003-09-15 06:40:47.0 -0700
 +++ 25-akpm/drivers/net/chelsio/gmac.h2005-03-11 11:13:06.0 
 -0800
 @@ -0,0 +1,126 @@
 +
 +typedef struct _cmac_instance cmac_instance;

Please drop the typedef.

 diff -puN /dev/null drivers/net/chelsio/osdep.h
 --- /dev/null 2003-09-15 06:40:47.0 -0700
 +++ 25-akpm/drivers/net/chelsio/osdep.h   2005-03-11 11:13:06.0 
 -0800
 @@ -0,0 +1,222 @@
 +#define DRV_NAME cxgb
 +#define PFX  DRV_NAME : 
 +
 +#define CH_ERR(fmt, ...)   printk(KERN_ERR PFX fmt, ## __VA_ARGS__)
 +#define CH_WARN(fmt, ...)  printk(KERN_WARNING PFX fmt, ## __VA_ARGS__)
 +#define CH_ALERT(fmt, ...) printk(KERN_ALERT PFX fmt, ## __VA_ARGS__)
 +
 +/*
 + * More powerful macro that selectively prints messages based on msg_enable.
 + * For info and debugging messages.
 + */
 +#define CH_MSG(adapter, level, category, fmt, ...) do { \
 + if ((adapter)-msg_enable  NETIF_MSG_##category) \
 + printk(KERN_##level PFX %s:  fmt, (adapter)-name, \
 +## __VA_ARGS__); \
 +} while (0)
 +
 +#ifdef DEBUG
 +# define CH_DBG(adapter, category, fmt, ...) \
 +CH_MSG(adapter, DEBUG, category, fmt, ## __VA_ARGS__)
 +#else
 +# define CH_DBG(fmt, ...)
 +#endif

Please consider using dev_* helpers from linux/device.h instead.

 +
 +/* Additional NETIF_MSG_* categories */
 +#define NETIF_MSG_MMIO 0x800
 +
 +#define CH_DEVICE(devid, ssid, idx) \
 + { PCI_VENDOR_ID_CHELSIO, devid, PCI_ANY_ID, ssid, 0, 0, idx }
 +
 +#define SUPPORTED_PAUSE   (1  13)
 +#define SUPPORTED_LOOPBACK(1  15)
 +
 +#define ADVERTISED_PAUSE  (1  13)
 +#define ADVERTISED_ASYM_PAUSE (1  14)
 +
 +/*
 + * Now that we have included the driver's main data structure,
 + * we typedef it to something the rest of the system understands.
 + */
 +typedef struct adapter adapter_t;

Please drop the typedef.

 +
 +#define DELAY_US(x) udelay(x)
 +
 +#define TPI_LOCK(adapter) spin_lock((adapter)-tpi_lock)
 +#define TPI_UNLOCK(adapter) spin_unlock((adapter)-tpi_lock)

Please drop the obfuscating wrappers.

 +void t1_elmer0_ext_intr(adapter_t *adapter);
 +void t1_link_changed(adapter_t *adapter, int port_id, int link_status,
 + int speed, int duplex, int fc);
 +
 +static inline void DELAY_MS(unsigned long ms)
 +{
 + unsigned long ticks = (ms * HZ + 999) / 1000 + 1;
 +
 + while (ticks) {
 + set_current_state(TASK_UNINTERRUPTIBLE);
 + ticks = schedule_timeout(ticks);
 + }
 +}

Use msleep here.

 diff -puN /dev/null drivers/net/chelsio/subr.c
 --- /dev/null 2003-09-15 06:40:47.0 -0700
 +++ 25-akpm/drivers/net/chelsio/subr.c2005-03-11 11:13:06.0 
 -0800
 +typedef struct {
 + u32 format_version;
 + u8 serial_number[16];
 + u8 mac_base_address[6];
 + u8 pad[2];   /* make multiple-of-4 size requirement explicit */
 +} chelsio_vpd_t;

Please drop the typedef.

Pekka
-
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: mousekeyboard with 2.6.10+

2005-03-14 Thread Michael Tokarev
Michael Tokarev wrote:
[]
2.6.10 almost works, but sometimes, the whole input
subsystem just hungs, ie, both keyboard and mouse
just stops working.  Plugging in USB keyboard and
loading usbhid module solves the problem - both
keyboards and the mouse works after that, and I
didn't yet notice the problem repeats after usbhid
and usb keyboard is loaded.  I wasn't able to
determine when the problem occurs, for me it seems
it hangs at some random point - sometimes after
5 minutes after boot, sometimes after a hour or
so.
Got another such hung and tried to debug it somehow.
Did a task dump (echo t  /proc/sysrq-trigger when logged
from network) -- nothing interesting; kseriod trace looks
a bit weird but it is as weird in normal mode too:
kseriod   S  0   196  1   361   122 (L-TLB)
c11f9f94 0046   c11f9000 c11f9000 c77d09e0 24de
   6b1f3a71 0004 c11f06bc c11f9fc0 c11f9000 c11f9fd4 f000 c01c4d4e
   c11f9000  c11f0560 c0127c20 c11f9fcc c11f9fcc c11f0560 c77c7f60
Call Trace:
 [c01c4d4e] serio_thread+0xbe/0x110
 [c0127c20] autoremove_wake_function+0x0/0x30
 [c0102c06] ret_from_fork+0x6/0x20
 [c0127c20] autoremove_wake_function+0x0/0x30
 [c01c4c90] serio_thread+0x0/0x110
 [c0101265] kernel_thread_helper+0x5/0x10
Everything on the system is sleeping.
After plugging in USB keyboard and loading uhci-hcd and
usbhid, the keyboard un-freeze, but mouse still didn't
work.  So I tried re-loading psmouse module, and
surprizingly, mouse started working again, but now dmesg
says:
 input: PS2++ Logitech Wheel Mouse on isa0060/serio1
(normally it's
 input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
)
and the mouse is moving very fast now.  Previously
I either didn't able to make it work at all after such
freeze, or it worked automatically after loading usbhid.
BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.
/mjt
-
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 1/2] uml: export getgid for hostfs

2005-03-14 Thread blaisorblade

Export this symbol which is now needed for a typo fix (getuid() - getgid()).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---

 linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c |1 +
 1 files changed, 1 insertion(+)

diff -puN arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs 
arch/um/os-Linux/user_syms.c
--- linux-2.6.11/arch/um/os-Linux/user_syms.c~uml-export-getgid-for-hostfs  
2005-03-11 20:16:17.061368376 +0100
+++ linux-2.6.11-paolo/arch/um/os-Linux/user_syms.c 2005-03-11 
20:16:17.065367768 +0100
@@ -82,6 +82,7 @@ EXPORT_SYMBOL_PROTO(statfs);
 EXPORT_SYMBOL_PROTO(statfs64);
 
 EXPORT_SYMBOL_PROTO(getuid);
+EXPORT_SYMBOL_PROTO(getgid);
 
 /*
  * Overrides for Emacs so that we follow Linus's tabbing style.
_
-
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] IBM TrackPoint support

2005-03-14 Thread Stephen Evanchik
On Mon, 14 Mar 2005 09:19:49 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
  +/*
  + * Mode manipulation
  + */
  +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */
  +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */
  +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */
 
 What exactly is transparent mode?

Transparency mode, when enabled, turns off the TrackPoint controller's
interpretation of the byte stream going to and coming from the
external PS/2 port if present.

Soft transparency mode can be cancelled, while hard transparency mode
requires a reset of the device and possibly the machine.

Stephen
-
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/1] uml-export-getgid-for-hostfs

2005-03-14 Thread Christoph Hellwig
  EXPORT_SYMBOL_PROTO(getuid);
 +EXPORT_SYMBOL_PROTO(getgid);

please don't.  as mentioned in the discussion about ROOT_DEV the whole
code using it is bogus.

-
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] IBM TrackPoint support

2005-03-14 Thread Vojtech Pavlik
On Mon, Mar 14, 2005 at 07:01:23AM -0500, Stephen Evanchik wrote:
 On Mon, 14 Mar 2005 09:19:49 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
   +/*
   + * Mode manipulation
   + */
   +#define TP_SET_SOFT_TRANS (0x4E) /* Set mode */
   +#define TP_CANCEL_SOFT_TRANS (0xB9) /* Cancel mode */
   +#define TP_SET_HARD_TRANS (0x45) /* Mode can only be set */
  
  What exactly is transparent mode?
 
 Transparency mode, when enabled, turns off the TrackPoint controller's
 interpretation of the byte stream going to and coming from the
 external PS/2 port if present.
 
 Soft transparency mode can be cancelled, while hard transparency mode
 requires a reset of the device and possibly the machine.
 
How much does it interpret the stream in non-transparent mode? Are
commands also passed through in soft transparent mode?

I'm asking because we might want to implement a passthrough port
similarly to what the Synaptics driver does and allow extended protocol
mice to be connected to the external mouse port.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: Strange memory leak in 2.6.x

2005-03-14 Thread Timo Hennerich
Hello,

my brother got ill this weekend, so I'll continue this task:

  See http://download.hennerich.de/kallsyms_20050312_1630.gz
 
 Great, just so that there is no confusion, I still need a new run
 of /proc/page_owner, the shorter time before the lockup the better.

The machine locked up this morning again. See

http://download.hennerich.de/page_owner_sorted_20050314_0740.bz2

for one of the last results of /proc/page_owner. It seems to be
obvious that the memory-leak seems to be the first entry:

$ less page_owner_sorted_20050314_0740.bz2
881397 times:
Page allocated via order 0
[0xc013962b] find_or_create_page+91
[0xf8aa9955] +613
[0xf8aaa606] +1366
[0xc015765c] vfs_write+172
[0xc015776c] sys_write+60
[0xc0103879] sysenter_past_esp+82
 
13358 times:
Page allocated via order 0
[0xc014817a] do_wp_page+282
[0xc014914e] handle_mm_fault+302
[0xc0113625] do_page_fault+501
[0xc0104a7b] error_code+43

The sorted table of /proc/kallsyms looks like this:

...
f8aa90e0 t reiserfs_commit_page [reiserfs]
f8aa92e0 t reiserfs_submit_file_region_for_write[reiserfs]
f8aa9550 t reiserfs_check_for_tail_and_convert  [reiserfs]
f8aa96f0 t reiserfs_prepare_file_region_for_write   [reiserfs]
f8aaa0b0 t reiserfs_file_write  [reiserfs]
f8aaa770 t reiserfs_aio_write   [reiserfs]
f8aaa779 t .text.lock.file  [reiserfs]
f8aaa7c0 t reiserfs_dir_fsync   [reiserfs]
f8aaa7f0 t reiserfs_readdir [reiserfs]
f8aaad70 t make_empty_dir_item_v1   [reiserfs]
f8aaae50 t make_empty_dir_item  [reiserfs]
f8aaafc0 t create_virtual_node  [reiserfs]
f8aab520 t check_left   [reiserfs]
f8aab670 t check_right  [reiserfs]
f8aab7c0 t get_num_ver  [reiserfs]
...

So I guess that we have a problem with the reiser filesystem??
We are using reiserfs 3.6...

Perhaps it's important to notice that the operating system

- is no fresh installation of SuSE 9.2, but was updated from SuSE 8.2
- is installed on that special hardware via a restore with the software
  Mondo-Rescue v2.03

Unfortunately we were not able up to now to reproduce the bug with
identical hardware and simulated disk-io. Only the production environment
triggers the bug.


0xf8aa9955 -  613 = 0xf8aa96f0: reiserfs_prepare_file_region_for_write
0xf8aaa606 - 1366 = 0xf8aaa0b0: reiserfs_file_write  

Wild guessing: Is reiserfs_prepare_file_region_for_write used
to append new output to existent files only - and do we have a memory
leak inside of this function? The production machine is used as loghost 
and syslog is writing several 100MB logfiles each day - which would be
a difference to the test hardware.



Best regards Timo
-- 
T+T Hennerich GmbH --- Zettachring 12a --- 70567 Stuttgart
Fon:+49(711)720714-0  Fax:+49(711)720714-44  Vanity:+49(700)HENNERICH
UNIX - Linux - Java - C  Entwicklung/Beratung/Betreuung/Schulung
http://www.hennerich.de/

-
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: cpufreq on-demand governor up_treshold?

2005-03-14 Thread Jan De Luyck
On Monday 14 March 2005 08:57, Eric Piel wrote:
 Jan De Luyck a écrit :
  Hello lists,
 
  (please cc me from cpufreq list)
 
  I've since yesterday started using the ondemand governor. Seems to work
  fine, tho I can't seem to find a reason why it keeps scaling my processor
  speed upwards tho the processor use never exceeds 30% (been watching top
  -d 1).
 
 
  Any hints?

 You can try the three attached patches in the order :
 ondemand-cleanup-factorise-idle-measurement-2.6.11.patch
 ondemand-save-idle-up-for-all-cpu-2.6.11.patch
 ondemand-automatic-downscaling-2.6.11-accepted.patch

 They are available on the cpufreq list but as it's difficult to access
 it I'm sending them again, all together. These are the last things that
 Venki and I have been working on. It should solve your problem
 (actually, only the last patch, but it depends on the two previous
 patches). Please, let me know if it works.

Okay, now the behaviour of the ondemand governor looks more 'sane'. Thanks, it 
looks like a huge improvement :)

Jan

-- 
Snow and adolescence are the only problems that disappear if you ignore
them long enough.
-
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/


Resending ethernet packets to direct neighbours

2005-03-14 Thread Weber Matthias
Hi,

i have a pc with five ethernet devices onto and want to resend ethernet packets 
coming in from one device to four direct neighbours (distance 1). Therefore i 
have installed a packet handler receiving skbs.
Now i have the following questions:
1) is it enough to change the skb-dev to the output device, rebuild the 
ethernet header and call dev_queue_xmit()?
2) how to i get the destination ethernet address of the physically direct 
neighbour within the packet handler? I believe, that i have to use the neighour 
caches but have not idea how...

Any help would be appreciated!


Bye
Matthias

-
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/


hold task lock question

2005-03-14 Thread Coywolf Qi Hunt
Hello,

Should we hold some lock (like task_lock(tsk)) when test tsk-mm == init_mm 
or any things else like tsk-mm ==0 ? Suppose it's the final test.

Thanks

-- 
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
-
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: about interrupt latency

2005-03-14 Thread zyphr
On Sat, 12 Mar 2005 10:01:43 -0700 (MST), Zwane Mwaikambo
[EMAIL PROTECTED] wrote:
 On Wed, 9 Mar 2005, Francesco Oppedisano wrote:
 
  On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo
  [EMAIL PROTECTED] wrote:
 
   At some cpu frequency point on i386 the main cause of your interrupt
   service latency will be in the interrupt controller and how long from irq
   assertion to the signal being recognised, resultant vector being
   dispatched to the processor and the necessary interrupt controller
   acknowledge steps required. This is also helped by the fact that the
   Linux/i386 interrupt vector stubs are very small and fast, so there isn't
   all that much code to execute to reach the ISR from the vector table. I'm
   not sure if you've tested this, but you may notice that timer interrupt
   via Local APIC will have lower dispatch latency than timer interrupt via
   i8259 only. But that's all at the lower end of the latency graph, you will
   most likely run into other sources on a busy system.
  
   Zwane
  
  Very interesting zwanei haven't tested the local APICdo you
  think this dispatch time can vary with the system I/O load (many
  pending interrupts in the PIC)?
 
 The PIC/i386 setup cannot really pend interrupts so i would say no i don't
 think the dispatch time would be affected.
 
  I think the interrupt latency is influenced even by the code inside
  the kernel: if a lot of code is running with interrupts disabled then
  the interrupt latency will grow. Am i right?
 
 Yes that's correct, in fact this will be your major/main cause of
 interrupt latency.
 
  So probably we can state that the factors influencing the interrupt latency 
  are:
  1)Dispatching time in the PIC
  2)Waiting time on the PIC (if there are pending interrupt of lower vector)
 
 With APIC/i386 this is more possible, if you're really interested you
 should try and calculate the dispatch time using the same system (must
 have an IOAPIC) and testing with the following combinations;
 
 PIC only (noapic, nolapic)
 PIC + LAPIC (noapic)
 IOAPIC + LAPIC
 
 You will probably find that the IOAPIC + LAPIC has the lowest dispatch
 time. Also worth noting that the LAPIC can queue upto 2 vectors (on P4),
 this allows for more interrupts to be ready for dispatch.
 
  3)fetching ISR from main memory
  4)wait time when CPU is running with disabled interrupt
 
  Do U agree?
 
 A bit more on (4)
 
 4a) wait time when CPU is running firmware (e.g. SMI/SMM, VGA BIOSes etc)
 
 Otherwise, yes i agree, good luck with your research.
 
 Zwane
 -
 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/
 

I am just a user, not sure if it is related.
But with CONFIG_X86_UP_APIC and/or  CONFIG_X86_UP_IOAPIC set my mouse
behaviour is totally different, when playing games everything feels
more laggy.
And it gives me what gamers call negative acceleration.
-
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: select() doesn't respect SO_RCVLOWAT ?

2005-03-14 Thread Alan Cox
On Gwe, 2005-03-11 at 20:26, Felix Matathias wrote:
 Dear Alan,
 
 I am positive. I can setsockopt, and then, getsockopt returns the value 
 that I requested.

Ok I misremembered - its SNDLOWAT that is locked to one in Linux.

 Stevens very clearly states that SO_RCVLOWAT has a direct impact on 
 select() and I assumed that this would be the case for Linux.
 What is the rationale for not complying with that ? Is it the micromanagement
 of select() that you dislike ? Isn't a significant reduction in the
 amount of read operations a real gain in high speed networking ?

I believe since we implement SO_SNDLOWAT that its a bug. Stevens and
1003.1g both agree with your expectations. The right list is probably
netdev@oss.sgi.com however.

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/


Re: select() doesn't respect SO_RCVLOWAT ?

2005-03-14 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B
In article [EMAIL PROTECTED] (at Mon, 14 Mar 2005 13:24:24 +), Alan Cox 
[EMAIL PROTECTED] says:

 1003.1g both agree with your expectations. The right list is probably
 netdev@oss.sgi.com however.

I've just forwarded this thread to netdev.

--yoshfuji
-
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: inconsistent kallsyms data [2.6.11-mm2]

2005-03-14 Thread Paulo Marques
Sam Ravnborg wrote:
On Thu, Mar 10, 2005 at 12:12:22PM +, Paulo Marques wrote:
Paulo Marques wrote:
[...]
A simple and robust way is to do the sampling on a list of symbols 
sorted by symbol name. This way, even if the symbol positions that are 
given to scripts/kallsyms change, the symbols sampled will be the same.

I'll do the patch to do this and send it ASAP.
Ok, here it is.
Dominik can you try the attached patch and see if it solves the problem?
Hi Paulo.
Hi Sam :)
Alexander Stohr had similar problems with down and __sched_text_start.
I figured out that what was causing the troubles was the fact that the
linker generated symbol __sched_text_start changed value from pass 1 to
pass 2. The reason for this was the alingment used within that section.
Damn, you're right. Looking more carefully at Dominik's files I can see 
that on the first pass we have:

T __sched_text_startPTR 0xc0420482
t __downPTR 0xc0420484
and on the second pass:
t __downPTR 0xc0420484
T __sched_text_startPTR 0xc0420484
I only looked at the addresses on the second pass and noticed they were 
aliased symbols and that the symbol order changed from the first pass :P

I never came around submitting this since I do not know what the correct
number for function alignment is on different paltforms.
If this will just align the beginning of a section, I don't think it 
will be a problem to always align at 8 bytes even on platforms that need 
only a 4 byte alignment.

So I think that your patch should definitely go in, as it solves a real 
problem.

As for my patch it could potentially solve problems that we don't 
currently have(*), so it is probably better to wait for them to appear 
before trying to solve an non-existent problem :)

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
(*) order of aliased symbols changing, or 'nm' returning non sorted 
addresses.
-
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: User mode drivers: part 1, interrupt handling (patch for 2.6.11)

2005-03-14 Thread Alan Cox
On Llu, 2005-03-14 at 00:02, Peter Chubb wrote:
 I can see there'd be problems if the code allowed shared interrupts,
 but it doesn't.

If you don't allow shared IRQ's its useless, if you do allow shared
IRQ's it deadlocks. Take your pick 8)

As to your comment about needing to do a few more I/O operations I
agree. However if your need is for speed then you might want to just
write a small IRQ helper module for the kernel or extend the syntax I
proposed a little (its conveniently trivial to generate native code from
this). 

There isn't much you can do about the status read without MWI on most
chip designs (some get it right by posting status to system memory but
not many)

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/


Re: User mode drivers: part 2: PCI device handling (patch 1/2 for 2.6.11)

2005-03-14 Thread Alan Cox
On Gwe, 2005-03-11 at 21:04, Albert Cahalan wrote:
  Still insufficient because the device might be hotplugged on you. You
  need a file handle that has the expected revocation effects on unplug
  and refcounts
 
 I was under the impression that a file handle would be returned.

Then lets use that popular open system call

-
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] IBM TrackPoint support

2005-03-14 Thread Stephen Evanchik
On Mon, 14 Mar 2005 13:19:56 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
 How much does it interpret the stream in non-transparent mode? Are
 commands also passed through in soft transparent mode?

 I'm asking because we might want to implement a passthrough port
 similarly to what the Synaptics driver does and allow extended protocol
 mice to be connected to the external mouse port.

I originally thought that I could implement something similar to the
Synaptics driver. Unfortunately, while in transparent mode bytes are
relayed unmodified with the TrackPoint controller disabled. In other
words, no simultaneous usage.

That doesn't mean extended protocol mice couldn't be supported in
transparent mode however. I didn't find it particularly useful given
the TrackPoint itself would be disabled.
-
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/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Segher Boessenkool
Sorry to follow up this late...
Is whitespace (in any form) allowed in the compatible value?
No.  Only printable characters are allowed, that is, byte values
0x21..0x7e and 0xa1..0xfe; each text string is terminated by a
0x00; there can be several text strings concatenated in one
compatible property.
Yes, whitespace is used at least in the toplevel compatible file, like
'Power Macintosh' in some Pismo models.
So those OF implementations violate the OF specification.
Oh well, it was wishful thinking anyway. ;)
I see two potential solutions:
* Ideally, I'd like to find a character (pipe?) that isn't used in the
  Apple OF compatible property. I've been unable to find any
  documentation that specifies to this level of detail. (Well, without
  paying for the IEEE-1275 reference, and it may not even be there.)
See 2.3.75 and 3.2.2.1.2 in the OF spec.
Segher
-
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: Strange memory leak in 2.6.x

2005-03-14 Thread Alexander Nyberg
   See http://download.hennerich.de/kallsyms_20050312_1630.gz
  
  Great, just so that there is no confusion, I still need a new run
  of /proc/page_owner, the shorter time before the lockup the better.
 
 The machine locked up this morning again. See
 
 http://download.hennerich.de/page_owner_sorted_20050314_0740.bz2
 
 for one of the last results of /proc/page_owner. It seems to be
 obvious that the memory-leak seems to be the first entry:
 
 $ less page_owner_sorted_20050314_0740.bz2
 881397 times:
 Page allocated via order 0
 [0xc013962b] find_or_create_page+91
 [0xf8aa9955] reiserfs_prepare_file_region_for_write+613
 [0xf8aaa606] reiserfs_file_write+1366
 [0xc015765c] vfs_write+172
 [0xc015776c] sys_write+60
 [0xc0103879] sysenter_past_esp+82

[resolved addresses = names]

 13358 times:
 Page allocated via order 0
 [0xc014817a] do_wp_page+282
 [0xc014914e] handle_mm_fault+302
 [0xc0113625] do_page_fault+501
 [0xc0104a7b] error_code+43
 
 The sorted table of /proc/kallsyms looks like this:
 
 ...
 f8aa90e0 t reiserfs_commit_page [reiserfs]
 f8aa92e0 t reiserfs_submit_file_region_for_write[reiserfs]
 f8aa9550 t reiserfs_check_for_tail_and_convert  [reiserfs]
 f8aa96f0 t reiserfs_prepare_file_region_for_write   [reiserfs]
 f8aaa0b0 t reiserfs_file_write  [reiserfs]
 f8aaa770 t reiserfs_aio_write   [reiserfs]
 f8aaa779 t .text.lock.file  [reiserfs]
 f8aaa7c0 t reiserfs_dir_fsync   [reiserfs]
 f8aaa7f0 t reiserfs_readdir [reiserfs]
 f8aaad70 t make_empty_dir_item_v1   [reiserfs]
 f8aaae50 t make_empty_dir_item  [reiserfs]
 f8aaafc0 t create_virtual_node  [reiserfs]
 f8aab520 t check_left   [reiserfs]
 f8aab670 t check_right  [reiserfs]
 f8aab7c0 t get_num_ver  [reiserfs]
 ...
 
 So I guess that we have a problem with the reiser filesystem??
 We are using reiserfs 3.6...
 
 Perhaps it's important to notice that the operating system
 
 - is no fresh installation of SuSE 9.2, but was updated from SuSE 8.2
 - is installed on that special hardware via a restore with the software
   Mondo-Rescue v2.03
 
 Unfortunately we were not able up to now to reproduce the bug with
 identical hardware and simulated disk-io. Only the production environment
 triggers the bug.
 
 
 0xf8aa9955 -  613 = 0xf8aa96f0: reiserfs_prepare_file_region_for_write
 0xf8aaa606 - 1366 = 0xf8aaa0b0: reiserfs_file_write  
 
 Wild guessing: Is reiserfs_prepare_file_region_for_write used
 to append new output to existent files only - and do we have a memory
 leak inside of this function? The production machine is used as loghost 
 and syslog is writing several 100MB logfiles each day - which would be
 a difference to the test hardware.

[added Vladimir Saveliev to CC]

The only thing that stands out is big page cache. However, looking at
the previous OOM output it shows that it is zone normal that is
completely out of memory and that highmem zone has lots of free memory.

Let's see if the big sharks know what is going on...

-
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/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Benjamin Herrenschmidt
On Sun, 2005-03-13 at 16:17 +0100, Segher Boessenkool wrote:
 Sorry to follow up this late...
 
  Is whitespace (in any form) allowed in the compatible value?
 
 No.  Only printable characters are allowed, that is, byte values
 0x21..0x7e and 0xa1..0xfe; each text string is terminated by a
 0x00; there can be several text strings concatenated in one
 compatible property.
 
  Yes, whitespace is used at least in the toplevel compatible file, like
  'Power Macintosh' in some Pismo models.
 
 So those OF implementations violate the OF specification.

Well, we have an unmaintained spec on one side that can't even be
ordered from IEEE anymore and actual imlementations that work today,
what do you chose ? ;)

Ben.


-
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/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Olaf Hering
 On Tue, Mar 15, Benjamin Herrenschmidt wrote:

 what do you chose ? ;)

I'm sure Rusty will prefer the non-whitespace version for depmod and
module.alias
-
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] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)

2005-03-14 Thread Mel Gorman
On Thu, 10 Mar 2005, Dave Hansen wrote:

 On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
  In particular, I am working on preparing a patch proposal for a policy
  that would kill a task rather than invoke the swapper.  In
  mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
  about to kick the swapper, if this policy is enabled (and you're not
  in_interrupt() and don't have flag PF_MEMALLOC set), then ask
  oom_kill_task() to shoot us instead.  For some big HPC jobs that are
  carefully sized to fit on the allowed memory nodes, swapping is a fate
  worse than death.
 
  The natural place (for me, anyway) to hang such policies is off the
  cpuset.
 

I have not read up on cpuset before so I am assuming you are talking about
http://www.bullopensource.org/cpuset/ so correct me if I am wrong.

  I am hopeful that cpusets will soon hit Linus's tree.
 
  Would it make sense to specify these buddy allocator fallback policies
  per cpuset as well?

 That seems reasonable, but I don't think there necessarily be enough
 cpuset users to make this reasonable as the only interface.

 Seems like something VMA-based along the lines of madvise() or the NUMA
 binding API would be more appropriate.  Perhaps default policies
 inherited from a cpuset, but overridden by other APIs would be a good
 compromise.


I would think that VMA is too fine-grained and there is not a really clean
way of specifying what fallback policy to use with madvise() unless we
hard-code a fixed number of policies.  I agree that if cpuset is not
widely used, it should not be the only way of setting policy. However, the
NUMA binding API deals with memory ranges, not PIDs. Implementing the
fallbacks for memory ranges would be at the node or zone level, not PID
which could be a conflict with cpuset (for example, which takes priority
when both cpuset and node policies are set?). So, I don't think the numa
binding as it is today is exactly the way to go either.

First though, we have to define how a fallback policy would be implemented
and applied.  Right now, there is one hard-coded policy (assuming that the
placement policy gets merged at some point in the future) that is
implemented in __rmqueue() and is applied at the zone level. It is
implemented as a while loop and the information it uses is;

Input: int[] Integer array of fallback allocation types
   struct zone * zone is the zone being allocated from
   int order being the required order

Output: struct free_area *area is the area we are going to allocate from
int current_order is the order of the free pages in area

So, a very rough fallback policy setup might look something like;

/*
 * Fallback function fills this struct telling the allocator where to get
 * free pages from
 */
struct fallback {
struct free_area*area;
unsigned long   current_order;
};

/* struct that describes a fallback policy */
struct fallback_policy {
void (*fallback)(int *fallback_list, struct zone* zone, int order);
char name[10];
int id; /* set on register */
}

/* List of all available fallback policies */
struct list_head *fallback_policies;

/* Default policy to use */
struct fallback_policy default_policy = {
.fallback = fallback_lowfrag,
.name = default,
.id = 0
};

/*
 * Register a new fallback policy. Throws a wobbly if the name is already
 * registered
 */
void register_fallback(struct fallback_policy *policy);

/* Unregister a fallback, calls BUG if policy == default_policy */
void unregister_fallback(struct fallback_policy *policy);

the fallback_lowfrag() function would just implement the current fallback
approach. Other users like hotplug or cpuset would create their own
fallback policy, populate a fallback_policy and register it. I think this
is similar to how IO schedulers are registered.

Next... How do we apply it.

I think the sensible level to have a fallback policy as at the mm_struct
level.  If the mm does not have a pointer to a fallback_policy, it uses
the default. This would be inherited from either a cpuset or explicitly
set via a specific API (should it inherit across exec()?  Initially, I
would think no)

Case 1: The cpuset case

cpuset has a pseudo filesystem called cfs that looks very like /sys
mounted on /dev/cpuset. Each directory under /dev/cpuset is a cpuset and
there are a number of files there. For fallbacks, a new file would be
there called fallback. Catting it would print something like

[default] hotplug noswapper

where the name between [] is what is currently set. To set a new fallback
policy, echo the new string name to fallback like

echo noswapper  fallback

Any process created with pexec() or is otherwise part of a cpuset will get
it's policy from here.

Case 2: Specific API

The NUMA binding API has a method that looks like this;

#include linux/mempolicy.h
int set_mempolicy(int policy, unsigned long *nodemask, unsigned long
maxnode)

We could have 

Re: [TTY] overrun notify issue during 5 minutes after booting

2005-03-14 Thread moreau francis

--- Andrew Morton [EMAIL PROTECTED] wrote:
 moreau francis [EMAIL PROTECTED] wrote:
 
 How does this look?
 

It works well though I haven't tested the second
correction. But it looks good...
By the way, is it safe in n_tty_receive_overrun to
call
printk ? because the former can be called from IT
context...

Francis 






Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.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: [PATCH 2/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Segher Boessenkool
Is whitespace (in any form) allowed in the compatible value?
No.  Only printable characters are allowed, that is, byte values
0x21..0x7e and 0xa1..0xfe; each text string is terminated by a
0x00; there can be several text strings concatenated in one
compatible property.
Yes, whitespace is used at least in the toplevel compatible file, 
like
'Power Macintosh' in some Pismo models.
So those OF implementations violate the OF specification.
Well, we have an unmaintained spec on one side that can't even be
ordered from IEEE anymore and actual imlementations that work today,
what do you chose ? ;)
I choose the spec.  If an implementation is not conformant to the spec,
it doesn't work.
Not to say that Linux doesn't have to work around bugs in actual
implementations, of course.  And there's a lot of those.  Too bad ;-)
Segher
-
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: mousekeyboard with 2.6.10+

2005-03-14 Thread Vojtech Pavlik
On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
 
 After plugging in USB keyboard and loading uhci-hcd and
 usbhid, the keyboard un-freeze, but mouse still didn't
 work.  So I tried re-loading psmouse module, and
 surprizingly, mouse started working again, but now dmesg
 says:
 
  input: PS2++ Logitech Wheel Mouse on isa0060/serio1
 
 (normally it's
  input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
 )
 
 and the mouse is moving very fast now.  Previously
 I either didn't able to make it work at all after such
 freeze, or it worked automatically after loading usbhid.
 
 BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.

Can you try 'usb-handoff' on the kernel command line?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: Call for help: list of machines with working S3

2005-03-14 Thread Jan De Luyck
On Monday 14 March 2005 09:00, Pavel Machek wrote:
 Hi!

* MySQL (hinders the actual suspension process and kicks the pc back to
  where it was)

 Try this patch...

Works nicely. Thanks.

Jan

-- 
Most people don't need a great deal of love nearly so much as they need
a steady supply.
-
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/


bug in kernel

2005-03-14 Thread Evgeniy
Here is a simple program.

#include stdio.h
#include errno.h
main(){
  int err;
  err=read(0,NULL,6);
  printf(%d %d\n,err,errno);
}

I think that it should be an error : Null pointer assignment, like in windows.
But in practise it is not so. 
Mandrake Linux kernel 2.4.21-0.13mdk
I am a programmer too and i am very interested to solve this problem. Please, 
send me fragment of sourse code of kernel with this bug.
Thanks.
Sorry for my English
-
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: bug in kernel

2005-03-14 Thread Arjan van de Ven
On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
 Here is a simple program.
 
 #include stdio.h
 #include errno.h
 main(){
   int err;
   err=read(0,NULL,6);
   printf(%d %d\n,err,errno);
 }
 
 I think that it should be an error : Null pointer assignment, like in windows.
 But in practise it is not so. 
 Mandrake Linux kernel 2.4.21-0.13mdk
 I am a programmer too and i am very interested to solve this problem. Please, 
 send me fragment of sourse code of kernel with this bug.

well what is the value of errno ?
-EFAULT by chance ?



-
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: bug in kernel

2005-03-14 Thread Arjan van de Ven
On Mon, 2005-03-14 at 15:51 +0100, Arjan van de Ven wrote:
 On Mon, 2005-03-14 at 17:48 +0300, Evgeniy wrote:
  Here is a simple program.
  
  #include stdio.h
  #include errno.h
  main(){
int err;
err=read(0,NULL,6);
printf(%d %d\n,err,errno);
  }
  
  I think that it should be an error : Null pointer assignment, like in 
  windows.
  But in practise it is not so. 
  Mandrake Linux kernel 2.4.21-0.13mdk
  I am a programmer too and i am very interested to solve this problem. 
  Please, 
  send me fragment of sourse code of kernel with this bug.
 
 well what is the value of errno ?
 -EFAULT by chance ?

note that you need to include unistd.h for the proper read() prototype
btw

-
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][-mm][1/2] cifs: whitespace cleanups for file.c

2005-03-14 Thread Steve French
OK - the first of them is merged in to the cifs bk tree.
The second one looks like an improvement on structuring of the cifs open
logic but needs review.  I may have a chance to test it later in the
week.

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/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Benjamin Herrenschmidt

  Well, we have an unmaintained spec on one side that can't even be
  ordered from IEEE anymore and actual imlementations that work today,
  what do you chose ? ;)
 
 I choose the spec.  If an implementation is not conformant to the spec,
 it doesn't work.
 
 Not to say that Linux doesn't have to work around bugs in actual
 implementations, of course.  And there's a lot of those.  Too bad ;-)

Yah, well.. ok, let's say we have a spec... and an implementation that
represents about 90% of the machines concerned. Those 90% have the
bug... what do you chose ? :) 

The separator in compatible, afaik, is \0, not space btw.

On possibiliy would be to have the kernel replace spaces with
underscores for the sake of matching. That would make life easier for
everybody.

Ben.


-
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.11-mm3: SIS5513 DMA problem (set_drive_speed_status)

2005-03-14 Thread Martin Zwickel
Hi,

just tried the 2.6.11-mm3 and at boot-time my start scripts try to
enable DMA on my disk (hdparm -m16 -c1 -u1 -X69 /dev/hda).

But while running hdparm, the kernel waits many seconds and gives me
some DMA warnings/errors:

[dmesg output]
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot :00:02.5
SIS5513: chipset revision 0
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: WDC WD1600JB-00GVA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: IDE DVD-ROM 16X, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 1024KiB
hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)
hda: cache flushes supported
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4  p5 p6 p7 p8 p9 
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20



BIOS EDD facility v0.16 2004-Jun-25, 1 devices found



hda: set_drive_speed_status: status=0xd0 { Busy }

ide: failed opcode was: unknown
hda: dma_timer_expiry: dma status == 0x41
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }

ide: failed opcode was: unknown
hda: DMA disabled
ide0: reset: success
hda: CHECK for good STATUS
hdc: Speed warnings UDMA 3/4/5 is not functional.
[/dmesg output]

That happened also with 2.6.11-rc3 since I thought I should switch away
from my 2.6.8-rc2-mm1 (the best kernel ever ;)).

In kernel config I enabled:
CONFIG_EDD=y

CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y

CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_ACPI=y


My machine:
Pentium 4 - 2,4Ghz


cat /proc/interrupts:
 14:  26411  XT-PIC  ide0
 15: 24  XT-PIC  ide1


lspci -vvxxx:
:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 
(prog-if 80 [Master])
Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller 
(A,B step)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 128
Region 4: I/O ports at ff00 [size=16]
00: 39 10 13 55 05 00 00 02 00 80 01 01 00 80 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 ff 00 00 00 00 00 00 00 00 00 00 39 10 13 55
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00
50: f2 00 f2 00 2a 96 d5 c0 00 00 00 00 00 00 00 00
60: fb aa fb aa 00 00 00 00 00 00 00 00 00 00 00 00
70: 17 21 06 04 00 00 00 00 56 23 06 04 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



Any hint/clue about that?

Regards,
Martin

-- 
MyExcuse:
Write-only-memory subsystem too slow for this machine. Contact your
local dealer.

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgpK2fapNoWAB.pgp
Description: PGP signature


Re: [PATCH 2/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Jeff Mahoney
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Benjamin Herrenschmidt wrote:
Well, we have an unmaintained spec on one side that can't even be
ordered from IEEE anymore and actual imlementations that work today,
what do you chose ? ;)

I choose the spec.  If an implementation is not conformant to the spec,
it doesn't work.

Not to say that Linux doesn't have to work around bugs in actual
implementations, of course.  And there's a lot of those.  Too bad ;-)
 
 
 Yah, well.. ok, let's say we have a spec... and an implementation that
 represents about 90% of the machines concerned. Those 90% have the
 bug... what do you chose ? :) 
 
 The separator in compatible, afaik, is \0, not space btw.
 
 On possibiliy would be to have the kernel replace spaces with
 underscores for the sake of matching. That would make life easier for
 everybody.

I had suggested this a few days ago, but got no response. Can we agree
that this would be an acceptable solution?

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCNauDLPWxlyuTD7IRAt+IAJ9mJRrrYT5trhv03qbGGPrwIwosqwCgpLS6
K/xQZE+dB4BPZc+R/FW74Nw=
=9Pgi
-END PGP SIGNATURE-
-
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/3] openfirmware: adds sysfs nodes for openfirmware devices

2005-03-14 Thread Segher Boessenkool
I choose the spec.  If an implementation is not conformant to the 
spec,
it doesn't work.

Not to say that Linux doesn't have to work around bugs in actual
implementations, of course.  And there's a lot of those.  Too bad ;-)
Yah, well.. ok, let's say we have a spec... and an implementation that
represents about 90% of the machines concerned. Those 90% have the
bug... what do you chose ? :)
What do you mean?  I already said we have to work around this bug --
but it IS a bug.  That's all.
The separator in compatible, afaik, is \0, not space btw.
Please re-read my original message?  Yes the separator is 0x00;
of course it isn't space, as space isn't allowed at all.
On possibiliy would be to have the kernel replace spaces with
underscores for the sake of matching. That would make life easier for
everybody.
Yes, that'll probably work just fine.  Or use 0xb1, showing that this
is plus-minus correct :-)
Segher
-
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: bug in kernel

2005-03-14 Thread Bernhard Rosenkraenzer
On Monday 14 March 2005 15:48, Evgeniy wrote:
 #include stdio.h
 #include errno.h
 main(){
   int err;
   err=read(0,NULL,6);
   printf(%d %d\n,err,errno);
 }

On my box (2.6.11), that does exactly what it is supposed to do -- -1 14
14 == EFAULT == Bad Address, which is what NULL is...

Btw, printf(%d %d %s\n, err, errno, strerror(errno)); gives you a more 
readable error, that would immediately show you did get the right error.
-
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 Making it possible to ignore blocked signals

2005-03-14 Thread Tobias Grundmann
Hi,
the following patch fixes the IMHO incorrect behavior to silently ignore 
attempts to set SIG_IGN on blocked signals (i.e. while running in a 
signal handler). See below for further explanation.

Tobias
--- kernel/signal.c.orig2005-03-06 18:12:26.0 +0100
+++ kernel/signal.c 2005-03-06 18:13:08.0 +0100
@@ -163,14 +163,6 @@
  if (t-ptrace  PT_PTRACED)
  return 0;
-   /*
-* Blocked signals are never ignored, since the
-* signal handler may change by the time it is
-* unblocked.
-*/
-   if (sigismember(t-blocked, sig))
-   return 0;
-
  /* Is it explicitly or implicitly ignored? */
  handler = t-sighand-action[sig-1].sa.sa_handler;
  return   handler == SIG_IGN ||
 Original Message 
Subject:PROBLEM: Ignoring blocked signals in 2.6 / 2.4 not possible
Date:   Sat, 26 Feb 2005 11:10:01 +0100
From:   [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
CC: [EMAIL PROTECTED]

Hi,
I have a question regarding blocked signals:
Is the current implementation to ignore attempts to set SIG_IGN on
blocked signals correct? 
The following code will go into an endless loop on kernels 2.6.10 and
2.4.25, which is IMHO not the behaviour one would expect. 


#include signal.h
#include sys/types.h
#include unistd.h
volatile int sig_received  = 0;
void sigio_handler_ex (int signum, siginfo_t * siginfo, void * ucontext)
{
  struct sigaction sigio_action;
  sig_received++;
  printf(handler %d\n,sig_received);
  sigio_action.sa_handler = SIG_IGN;
  sigio_action.sa_flags = 0;
  sigemptyset(sigio_action.sa_mask);
  sigaction (SIGIO, sigio_action, 0);
  kill(getpid(),SIGIO);
  sigio_action.sa_sigaction =  sigio_handler_ex;
  sigio_action.sa_flags = SA_SIGINFO;
  sigemptyset(sigio_action.sa_mask);
  sigaction (SIGIO, sigio_action, 0);
}
int main(int argc, char **argv) {
  struct sigaction sigio_action;
  sigio_action.sa_sigaction =  sigio_handler_ex;
  sigio_action.sa_flags = SA_SIGINFO;
  sigemptyset(sigio_action.sa_mask);
  sigaction (SIGIO, sigio_action, 0);
  kill(getpid(),SIGIO);
  while  (! sig_received) {
  printf(waiting for signal\n);
  sleep(1);
  }
  kill(getpid(),SIGIO);
  printf(%d signals handled\n,sig_received);
}

In kernel 2.6.10/kernel/signal.c sig_ignored() I found this comment:
...
/*
* Blocked signals are never ignored, since the
* signal handler may change by the time it is
* unblocked.
*/
if (sigismember(t-blocked, sig))
return 0;
...
so it seems this behaviour is intentional, but I don't understand
it. Why should it matter if a signal handler may change while blocked,
if it is ignored also, which is a user request?
The machine im writing this mail on runs with the above lines
commented out without any problems so far...
All this resulted from problems a customer had with implementing a
whole protocol-stack to a serially attached device in a
signal-handler. After the handler ran (with SIG_IGN) there was always
an extra SIGIO which triggered the handler again. Of course the real
fix was to move the protocol-stack out of the handler but still it
should have worked since it was a controlled environment (so there
wasn't even a race between entering the handler and setting
SIG_IGN). Oh and it worked for years under some realtime variant of
hp-unix.
Please be so kind to CC any answer to me directly since I'm
currently not subscribed to lkml.
Yours
Tobias Grundmann
-
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/


Error in creating /proc file

2005-03-14 Thread sounak chakraborty
dear sir,
i am actually trying to create a thread directory in
which files will be created by the name of the thread
id
which will contain the basic information about the
thread
(similar to process concept of kernel)
but i want to the detail steps about how the kernel
implements its process information inside
the proc file so that i can do it similar kind in case
of creating for the threads.

the first basic problem is the 
according to me the 
1.the actual processes are creting in the do_fork
function and from there the 
  information is passed to the fs/proc  in the
functions present in the generic and base.c
  am i currect or the fs/proc is collecting the data
from the current 

  but in this case i was applying a shortcuts as i was
waiting for any proc file in the kernel to be written 
  during startup and the setting a global variable in
fs/proc/base.c after that in the
  do_fork the function waits for the global variable
to be turned on and after that calls anather function
  which creates proc files through the use of
create_proc_entry.

  but during startup the following errors are coming 
  
*pde=
Oops: [#1]
PREEMPT
Modules link in: 
CPU: 0
EIP: 0060:[c011d99c] Not tainted
EFLAGS: 00010202 (2.6.8)
EIP is at register_proc_table+0xdc/0x130

eax: ebx:c0321d40 ecx:1006
edx:c02e28c5
esi: edi: ebp:0006
esp:c7e95fb0
ds: 007b es: 007b ss:0068
 
Process Swapper(pid :1,threadinfo =c7e94000
task=c7e93670)
Stack: c03635e4 c03635e4 c03635e4 416d
00100410  
   c03a8ee8 c0321d40  c039e8ac
c0100445 007b 
   c01040e0 c01040e5  
 

   Call Trace :
 [c0100410] init+0x0/0x158 
 [c03a8338] sysctl_init+0x18/0x20
 [c039e8aa] do_basic_setup+0xa/0x20
 [c0100445] init+0x35/0x158
 [c01040e0] kernel_thread_helper+0x0/0x10
 [c01040e5] kernel_thread_helper+0x5/0x10
 
 Code: 8b 78 34 85 ff 74 b7 8d b6 
   00 00 00 00 8d bc 27 00 00 
   00 00
 0 Kernel panic : Attempted to kill init!

   
  


  


2.if i am in a wrong way i could do the implementation
in the following manner in which the 
  kernel implements the proc system of its process
part.
  but i am really confused about that one .i need some
kind of help in that case 
  is it necessary to do all the details implementation
like inode creating which are all being done 
  in the generic and base.c  or i can simply bypass
them with   create_proc_entry

  what should i do 
  
 suggest me some architecture to implement the thread
proc system 

i can a way out 
and i cant able to understand where i am wrong
thanks in advance
sounak


Yahoo! India Matrimony: Find your partner online. 
http://yahoo.shaadi.com/india-matrimony/
-
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][-mm][1/2] cifs: whitespace cleanups for file.c

2005-03-14 Thread Jesper Juhl
On Mon, 14 Mar 2005, Steve French wrote:

 OK - the first of them is merged in to the cifs bk tree.

Thank you.


 The second one looks like an improvement on structuring of the cifs open
 logic but needs review.

Yes, it certainly does. I may be able to install windows in vmware or 
borrow a machine for it during the week to test the patch a bit myself, 
I'll see what I can do.


  I may have a chance to test it later in the
 week.
 
Great.


 Thanks.
 
You're very welcome.

Would it be useful if I split the second patch into a few parts for you? I 
could split some of the (non cifs_open related) whitespace changes into 
one, the kfree related changes into another and then a third with the 
cifs_open rework. Would that make things easier for you?


-- 
Jesper


-
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: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-14 Thread John W. Linville
On Mon, Mar 14, 2005 at 03:59:06AM -0500, Greg Stark wrote:

 Well, I built a slew of kernels but found it on the first reboot.
 
 2.6.7 doesn't work.
 
  2.6.7:

  [sound/oss] remove bogus CIV_TO_LVI
  
  This patch removes a pair of bogus LVI assignments.  The explanation in
  the comment is wrong because the value of PCIB tells the hardware that
  the DMA buffer can be processed even if LVI == CIV.
  
  Setting LVI to CIV + 1 causes overruns when with short writes
  (something that vmware is very fond of).

Pretty sure this is/was the problem.  I found this to be causing
a problem with Wolfenstein: Enemy Territory.  The patch to reverse
this change appears to have been merged into 2.6.11.  I suggest you
try that one. :-)

Good luck!

John
-- 
John W. Linville
[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: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-14 Thread Greg Stark
Andrew Morton [EMAIL PROTECTED] writes:

 Herbert tells me that this might be fixed in 2.6.11.  Did you try that?

Nope. I'll try that. 


(Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but
now it's fixed without any reports?)

-- 
greg

-
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: bug in kernel

2005-03-14 Thread Pat Kane
I ran the little test program on my 2.4.26  Knoppix system, and got the 
following two results:

 strace a.out  /dev/tty
  ...
  read(0, NULL, 6)= 1
  ...
 strace a.out  /dev/zero
  ...
  read(0, 0, 6)   = -1 EFAULT (Bad address)
  ...
The first case looks broken.
Pat
---

-
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.11-rc3-V0.7.38-01

2005-03-14 Thread Steven Rostedt


On Mon, 14 Mar 2005, Steven Rostedt wrote:

 On Mon, 14 Mar 2005, Steven Rostedt wrote:
 
  I just downloaded -40 and applied my patch, compiled it with
  PREEMPT_DESKTOP and data=ordered, ran it and everything seems OK, except
  I'm getting the following...
 
  BUG: Unable to handle kernel NULL pointer dereference at virtual address
  
   printing eip:
  c0213438
  *pde = 

 [snip]

 
 
  I'll see if this happens without the patch, and if so, then I'll look into
  this further.
 

 Well, I took out my patch and this bug didn't happen, so I guess it's may
 fault!  OK, I'll dig into it further.


Here's a new patch. All I did was move BUFFER_FNS(JournalHead,journalhead)
to inside the #ifdef CONFIG_PREEMPT_RT and my oops went away !?!  This
really bothers me since it just declares some functions and is not used
with CONFIG_PREEMPT_RT off.  I have no idea what's going on.

Lee, can you see if this still crashes for you.


Thanks,

-- Steve


diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 
linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/journal.c 2005-03-02 
02:37:49.0 -0500
+++ linux-2.6.11-final-V0.7.40-00/fs/jbd/journal.c  2005-03-14 
09:46:41.0 -0500
@@ -80,6 +80,10 @@
 EXPORT_SYMBOL(journal_try_to_free_buffers);
 EXPORT_SYMBOL(journal_force_commit);

+#ifdef CONFIG_PREEMPT_RT
+spinlock_t jbd_journal_head_lock = SPIN_LOCK_UNLOCKED;
+#endif
+
 static int journal_convert_superblock_v1(journal_t *, journal_superblock_t *);

 /*
@@ -1727,6 +1731,9 @@
jh = new_jh;
new_jh = NULL;  /* We consumed it */
set_buffer_jbd(bh);
+#ifdef CONFIG_PREEMPT_RT
+   spin_lock_init(jh-b_state_lock);
+#endif
bh-b_private = jh;
jh-b_bh = bh;
get_bh(bh);
@@ -1767,26 +1774,34 @@
if (jh-b_transaction == NULL 
jh-b_next_transaction == NULL 
jh-b_cp_transaction == NULL) {
-   J_ASSERT_BH(bh, buffer_jbd(bh));
-   J_ASSERT_BH(bh, jh2bh(jh) == bh);
-   BUFFER_TRACE(bh, remove journal_head);
-   if (jh-b_frozen_data) {
-   printk(KERN_WARNING %s: freeing 
-   b_frozen_data\n,
-   __FUNCTION__);
-   kfree(jh-b_frozen_data);
-   }
-   if (jh-b_committed_data) {
-   printk(KERN_WARNING %s: freeing 
-   b_committed_data\n,
-   __FUNCTION__);
-   kfree(jh-b_committed_data);
+#ifdef CONFIG_PREEMPT_RT
+   if (atomic_read(jh-b_state_wait_count)) {
+   BUG_ON(buffer_journalhead(bh));
+   set_buffer_journalhead(bh);
+   } else
+#endif
+   {
+   J_ASSERT_BH(bh, buffer_jbd(bh));
+   J_ASSERT_BH(bh, jh2bh(jh) == bh);
+   BUFFER_TRACE(bh, remove journal_head);
+   if (jh-b_frozen_data) {
+   printk(KERN_WARNING %s: freeing 
+  b_frozen_data\n,
+  __FUNCTION__);
+   kfree(jh-b_frozen_data);
+   }
+   if (jh-b_committed_data) {
+   printk(KERN_WARNING %s: freeing 
+  b_committed_data\n,
+  __FUNCTION__);
+   kfree(jh-b_committed_data);
+   }
+   bh-b_private = NULL;
+   jh-b_bh = NULL;/* debug, really */
+   clear_buffer_jbd(bh);
+   __brelse(bh);
+   journal_free_journal_head(jh);
}
-   bh-b_private = NULL;
-   jh-b_bh = NULL;/* debug, really */
-   clear_buffer_jbd(bh);
-   __brelse(bh);
-   journal_free_journal_head(jh);
} else {
BUFFER_TRACE(bh, journal_head was locked);
}
diff -ur linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/transaction.c 
linux-2.6.11-final-V0.7.40-00/fs/jbd/transaction.c
--- linux-2.6.11-final-V0.7.40-00.orig/fs/jbd/transaction.c 2005-03-02 
02:37:53.0 -0500
+++ 

Re: OSS Audio borked between 2.6.6 and 2.6.10

2005-03-14 Thread John W. Linville
On Mon, Mar 14, 2005 at 10:40:27AM -0500, Greg Stark wrote:
 Andrew Morton [EMAIL PROTECTED] writes:
 
  Herbert tells me that this might be fixed in 2.6.11.  Did you try that?
 
 Nope. I'll try that. 
 
 
 (Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but
 now it's fixed without any reports?)

(Presuming that the Quake3 problem is the same as the Wolfenstein:
ET problem...)

It was reported as a problem with RHEL3.  When I discovered the fix,
I pushed it to the OSS drivers in 2.6.x as well.

John
-- 
John W. Linville
[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: mousekeyboard with 2.6.10+

2005-03-14 Thread Michael Tokarev
Vojtech Pavlik wrote:
On Mon, Mar 14, 2005 at 02:52:00PM +0300, Michael Tokarev wrote:
 

After plugging in USB keyboard and loading uhci-hcd and
usbhid, the keyboard un-freeze, but mouse still didn't
work.  So I tried re-loading psmouse module, and
surprizingly, mouse started working again, but now dmesg
says:
input: PS2++ Logitech Wheel Mouse on isa0060/serio1
(normally it's
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
)
and the mouse is moving very fast now.  Previously
I either didn't able to make it work at all after such
freeze, or it worked automatically after loading usbhid.
BTW, it's 2.6.10, I can't made it work with 2.6.11 at all.

Can you try 'usb-handoff' on the kernel command line?
The problem has nothing to do with USB per se, as far as
I can see.  PS2 keyboard and mouse does not work when
the USB subsystem (incl. usbcore) is not loaded.  And the
problem is with PS2 keyboard/mouse, not with USB one which
works just fine.
/mjt
-
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: bug in kernel

2005-03-14 Thread Martin Zwickel
On Mon, 14 Mar 2005 17:48:05 +0300
Evgeniy [EMAIL PROTECTED] bubbled:

 Here is a simple program.
 
 #include stdio.h
 #include errno.h
 main(){
   int err;
   err=read(0,NULL,6);
   printf(%d %d\n,err,errno);
 }

Results:
# ./a  /dev/zero 
read(0, 0, 6)   = -1 EFAULT (Bad address)
-1 14 Bad address

So everything is fine...

Regards,
Martin

-- 
MyExcuse:
I'd love to help you -- it's just that the Boss won't let me near the
computer.

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgplZHvOVnbQ3.pgp
Description: PGP signature


Re: [PATCH][-mm][1/2] cifs: whitespace cleanups for file.c

2005-03-14 Thread Steve French
On Mon, 2005-03-14 at 09:36, Jesper Juhl wrote:

 Would it be useful if I split the second patch into a few parts for you? I 
 could split some of the (non cifs_open related) whitespace changes into 
 one, the kfree related changes into another and then a third with the 
 cifs_open rework. Would that make things easier for you?
 

For the second patch (the one I did not apply) slightly smaller would
make things easier.  For patches that have non-trivial changes - my
preference is to split the patches into the 50-200 line range since they
can be reviewed and put in incrementally.

 I may be able to install windows in vmware or borrow a machine
WindowsXP, Linux/Samba3, LinuxSamba4, Windows2000, Windows2003, etc.
have been very easy to get a hold of and test.  

I have been having a very hard time getting a usable WindowsNT
(and Windows9x) server for testing (I do have one of each at work I can test
against but at home it makes it tough to test).   With the latest vmware, my 
last shot at NT4 install failed (not sure why yet - perhaps NT4 does
not like vmware emulated SCSI and wants IDE only) - at work we have NT4 
in the older vmware working fine but I want to test it on NT4 and Win9x/WinME 
more,
since they get run the least and are much worse servers than Windows200x, XP 
and Samba
so test feedback on those on current kernel would be useful.l

Also there are other CIFS server out there - at Connectathon a few weeks ago 
the testing was very helpful.  Compensating for the minor differences among the
server like NetApp, BlueArc, AIX FastConnect etc. is important - and I don't 
have 
those servers easily accessible to test against.   I am especially interested 
in test feedback with current kernel/cifs against those with other
servers (not just the usual Samba3, Samba4, current Windows).

-
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][-mm][1/2] cifs: whitespace cleanups for file.c

2005-03-14 Thread Jesper Juhl
On Mon, 14 Mar 2005, Steve French wrote:

 On Mon, 2005-03-14 at 09:36, Jesper Juhl wrote:
 
  Would it be useful if I split the second patch into a few parts for you? I 
 
 For the second patch (the one I did not apply) slightly smaller would
 make things easier.  For patches that have non-trivial changes - my
 preference is to split the patches into the 50-200 line range since they
 can be reviewed and put in incrementally.
 
I'll sort that out and send you such patches later this evening.


 those servers easily accessible to test against.   I am especially interested 
 in test feedback with current kernel/cifs against those with other
 servers (not just the usual Samba3, Samba4, current Windows).
 
All I can get hold of easily is Samba3/4 on Linux, and probably Win2K. 
I /might/ be able to get hold of other stuff through work, but don't count 
on it. I'll see what I can do.


-- 
Jesper 

-
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/


  1   2   3   4   >