Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit

[Shawn Starr]

You know, after seeing that patch, that it just makes sense to add some of
those cleanups to the lm80 driver.

Shawn.

lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V:   +4.90 V  (min =  +4.74 V, max =  +5.25 V)
VTT:   +1.72 V  (min =  +1.70 V, max =  +2.10 V)
+3.3V: +3.35 V  (min =  +3.14 V, max =  +3.47 V)
+Vcore:+1.98 V  (min =  +1.90 V, max =  +2.10 V)
+12V: +11.30 V  (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V  (min = -12.60 V, max = -11.39 V)
-5V:   -4.92 V  (min =  -5.25 V, max =  -4.76 V)
fan1: 1679 RPM  (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
:  (os:  limit = +54°C, hyst = +56°C)

Driver works with changes applied.

Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>

* Note to self, dont use Kmail for raw diff files
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c	2005-01-26 02:04:38.0 -0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c	2005-01-26 02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
 
 static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
 {
-	if (rpm == 0)
+	if (rpm <= 0)
 		return 255;
 	rpm = SENSORS_LIMIT(rpm, 1, 100);
 	return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
 #define TEMP_LIMIT_TO_REG(val)		SENSORS_LIMIT((val)<0?\
 	((val)-500)/1000:((val)+500)/1000,0,255)
 
-#define ALARMS_FROM_REG(val)		(val)
-
 #define DIV_FROM_REG(val)		(1 << (val))
-#define DIV_TO_REG(val)			((val)==8?3:(val)==4?2:(val)==1?0:1)
 
 /*
  * Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
 			   DIV_FROM_REG(data->fan_div[nr]));
 
 	val = simple_strtoul(buf, NULL, 10);
-	data->fan_div[nr] = DIV_TO_REG(val);
+
+	switch (val) {
+	case 1: data->fan_div[nr] = 0; break;
+	case 2: data->fan_div[nr] = 1; break;
+	case 4: data->fan_div[nr] = 2; break;
+	case 8: data->fan_div[nr] = 3; break;
+	default:
+		dev_err(>dev, "fan_div value %ld not "
+			"supported. Choose one of 1, 2, 4 or 8!\n", val);
+		return -EINVAL;
+	}
 
 	reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr + 1
 	| (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
 static ssize_t show_alarms(struct device *dev, char *buf)
 {
 	struct lm80_data *data = lm80_update_device(dev);
-	return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+	return sprintf(buf, "%u\n", data->alarms);
 }
 
 static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);

[PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)

[Shawn Starr]

You know, after seeing that patch, that it just makes sense to add some of 
those cleanups to the lm80 driver.

Shawn.

lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V:   +4.90 V  (min =  +4.74 V, max =  +5.25 V)
VTT:   +1.72 V  (min =  +1.70 V, max =  +2.10 V)
+3.3V: +3.35 V  (min =  +3.14 V, max =  +3.47 V)
+Vcore:+1.98 V  (min =  +1.90 V, max =  +2.10 V)
+12V: +11.30 V  (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V  (min = -12.60 V, max = -11.39 V)
-5V:   -4.92 V  (min =  -5.25 V, max =  -4.76 V)
fan1: 1679 RPM  (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
:  (os:  limit = +54°C, hyst = +56°C)

Driver works with changes applied.

Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>

--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0 
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26 
02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
 
 static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
 {
- if (rpm == 0)
+ if (rpm <= 0)
   return 255;
  rpm = SENSORS_LIMIT(rpm, 1, 100);
  return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
 #define TEMP_LIMIT_TO_REG(val)  SENSORS_LIMIT((val)<0?\
  ((val)-500)/1000:((val)+500)/1000,0,255)
 
-#define ALARMS_FROM_REG(val)  (val)
-
 #define DIV_FROM_REG(val)  (1 << (val))
-#define DIV_TO_REG(val)   ((val)==8?3:(val)==4?2:(val)==1?0:1)
 
 /*
  * Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
   DIV_FROM_REG(data->fan_div[nr]));
 
  val = simple_strtoul(buf, NULL, 10);
- data->fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data->fan_div[nr] = 0; break;
+ case 2: data->fan_div[nr] = 1; break;
+ case 4: data->fan_div[nr] = 2; break;
+ case 8: data->fan_div[nr] = 3; break;
+ default:
+  dev_err(>dev, "fan_div value %ld not "
+   "supported. Choose one of 1, 2, 4 or 8!\n", val);
+  return -EINVAL;
+ }
 
  reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr + 1
  | (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
 static ssize_t show_alarms(struct device *dev, char *buf)
 {
  struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+ return sprintf(buf, "%u\n", data->alarms);
 }
 
 static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
-
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] update Dag Brattli's email address

[Adrian Bunk]

On Tue, Jan 25, 2005 at 04:52:15PM -0800, Chris Wedgwood wrote:
> On Tue, Jan 25, 2005 at 03:40:46PM +0100, Adrian Bunk wrote:
> 
> > This patch updates the email address of Dag Brattli in kernel 2.6 to
> > his current address.
> 
> >  drivers/net/irda/actisys-sir.c|4 ++--
> [ ... 
> >  CREDITS   |6 +-
> >  96 files changed, 233 insertions(+), 237 deletions(-)
> 
> This patch is huge.
> 
> Do we really need email addresses in all these files?  How about we
> remove them and put it in ONE place instead so if it needs to be
> updated again we don't need to touch ~96 files?
> 
> Surely this makes sense in general too?

I have no strong opinions on this - in most places a simple removal of 
his email address might do as well.

But at least the CREDITS file and the 17 files where the address is 
listed in MODULE_AUTHOR need the correct address.

cu
Adrian

-- 

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

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

Re: [PATCH] Use MM_VM_SIZE in exit_mmap

[William Lee Irwin III]

Anton Blanchard <[EMAIL PROTECTED]> writes:
>> It is possible for one task to end up "owning" an mm from another - we
>> have seen this with the procfs code when process 1 accesses
>> /proc/pid/cmdline of process 2 while it is exiting.  Process 2 exits
>> but does not tear its mm down. Later on process 1 finishes with the proc
>> file and the mm gets torn down at this point.

On Wed, Jan 26, 2005 at 07:44:24AM +0100, Andi Kleen wrote:
> IMHO that's the root bug. That sounds really dangerous and will likely
> cause other problems because it is totally unexpected. How about fixing
> /proc to not do this?

It would not be meaningful. It's a natural outcome of reference
counting the mm, /proc/ is far from the only place that acquires
references on mm's, and they're all necessary.


-- wli
-
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-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Ingo Molnar]

* Jack O'Quin <[EMAIL PROTECTED]> wrote:

> >> The equivalent rlimits experiment probably requires:
> >> 
> >>   (1) editing /etc/security/limits.conf
> >>   (2) shutting everything down
> >>   (3) logout
> >>   (4) login
> >>   (5) restarting the test
> >
> > well, there's setrlimit, so you could add a jackd client callback that
> > instructs all clients to change their RT_CPU_RATIO rlimit. In theory we
> > could try to add a new rlimit syscall that changes another task's rlimit
> > (right now the syscalls only allow the changing of the rlimit of the
> > current task) - that would enable utilities to change the rlimit of all
> > tasks in the system, achieving the equivalent of a global sysctl.
> 
> Sure, we could.  That does seem like an enormously complicated
> mechanism to accomplish something so simple.  We are taking a global
> per-CPU limit, treating it as if it were per-process, then invoking a
> complex callback scheme to propagate new values, [...]

this was just a suggestion. It seems a remote-rlimit syscall is
possible, so there's no need to change Jack if you dont want to - that
syscall enables a utility that will change the rlimit for all running
tasks, so you'll get the 'simplicity of experimentation' of a global
sysctl.

(what you wont get is the ultra-fast time-to-market property of sysctl
hacks. I know that you'd probably prefer a global sysctl that you could
start using tomorrow, and i also know that the global sysctl would
suffice current Jackd needs, but we cannot sacrifice flexibility and
future utility for the sake of a couple of weeks/months of time
advantage...)

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: User space out of memory approach

[Thomas Gleixner]

On Tue, 2005-01-25 at 20:11 -0400, Mauricio Lin wrote:
> > Can you please show the kernel messages ?
> 
> OK. We will try to reach a situation that the printk messages can be
> written entirely in the log file and show you the kernel messages. But
> as I said: usually the printks messages are not written in the log
> file using Andrea's patch. But using the original OOM Killer we can
> see the messages in the log file. The syslog.conf file is the same for
> both OOM Killer(Andrea and Original). Do you have any idea what is
> happening to log file?

Add "console=ttyS0,115200" to your commandline so you get all the
messages on the serial console.

tglx


-
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: error while recompinling linux kernel

[Jurriaan on adsl-gate]

On Wed, Jan 26, 2005 at 01:44:41AM -0500, [EMAIL PROTECTED] wrote:
> Hi,
> 
> I am a beginer in linux. I tried to recomplile kernel 2.4.9 and I
> encountered following error 
> 
> make[3]: *** [am79c961a.o] Error 1
> make[3]: Leaving directory `/usr/src/linux/drivers/net'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/usr/src/linux/drivers/net'
> make[1]: *** [_subdir_net] Error 2
> make[1]: Leaving directory `/usr/src/linux/drivers'
> make: *** [_dir_drivers] Error 2
> 
> can you someone help me please?
> 
The interesting line is just above the part you posted - the actual
error message. Also, 2.4.9 is ancient - current kernel is 2.4.29 IIRC.

Good luck,
Jurriaan
-
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-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Ingo Molnar]

* Jack O'Quin <[EMAIL PROTECTED]> wrote:

> >   http://redhat.com/~mingo/rt-limit-patches/
> >
> > i've removed the global sysctl and implemented a new rlimit,
> > RT_CPU_RATIO: the maximum amount of CPU time RT tasks may use, in
> > percent. For testing purposes it defaults to 80%.
> 
> Small terminology quibble: `ratio' sounds like a fraction, not a
> percentage.  Since it really is a percentage, why not call it
> RLIMIT_RT_CPU_PERCENT, or (maybe better) just RLIMIT_RT_CPU?

yeah, makes sense. I've uploaded the -D5 patch, which has the following 
changes:

 - renamed the rlimit to RLIMIT_RT_CPU

 - exported the current RT-average value to /proc/stat (it's the last 
   field in the cpu lines)

> Does getrusage() return anything for this?  How can a field be added
> to the rusage struct without breaking binary compatibility?  Can we
> assume that no programs ever use sizeof(struct rusage)?

rlimits are easily extended and there are no binary compatibility
worries. The kernel doesnt export the maximum towards userspace. 
getrusage() will return the value on new kernels and will return -EINVAL
on old kernels, so new userspace can deal with this accordingly.

> I can imagine defining per-user limits based on membership in groups
> like `audio', `video' or `cdrom'.  While logical, I'm having trouble
> thinking of usage scenarios where it makes any practical difference.

e.g. the issue Con and others raised: privileged tasks. By default, the
root user will likely have a 0 rlimit, for compatibility. _But_ i can
easily imagine users wanting to put in a safety limit even for
root-owned RT tasks by making the rlimit 98% or so. Nonprivileged users
would have this rlimit at say 20% in a typical desktop distribution.

> > multiple tasks can have different rlimits as well, and the scheduler
> > interprets it the following way: it maintains a per-CPU "RT CPU use"
> > load-average value and compares it against the per-task rlimit. If e.g. 
> > the task says "i'm in the 60% range" and the current average is 70%,
> > then the scheduler delays this RT task - if the next task has an 80%
> > rlimit then it will be allowed to run. This logic is straightforward and
> > can be used as a further control mechanism against runaway highprio RT
> > tasks.
> 
> I can almost understand how this works, but not quite.  I guess I need
> to read the code.  You're trying to selectively throttle certain tasks
> and not others, right? [...]

correct.

> [...] But, the limit they're hitting is system global.

no, the limit is per-task. It is the _current CPU average_, measured by
the scheduler, that is global. (well, on SMP: "per-CPU global".) This
means that the scheduler knows all the time the percentage of time RT
tasks use up. If it's say 76%, and the rlimit of the _current task_ is
at 90% then this task will be allowed to run. (up to the point the
average reaches 90%.) If this task finishes running, and another RT task
would like to run, and we are still at a 76% RT-average, and that new
task has a 60% rlimit, then the scheduler will not allow the new task to
run. Only tasks that are SCHED_OTHER, or have a higher RT rlimit than
the current average will be allowed to run. [except if there are no
SCHED_OTHER tasks, in which case all tasks are allowed to run.]

> So, what does it mean for a task to say "I'm in the 60% range"?  That
> it individually will never use more than 60% of any one CPU?  Or, that
> it and several other associated tasks will never use more than that?

it means that it will only be allowed to run if the CPU utilization of
all RT tasks (eligible to run) do not exceed 60%.

> > other properties of the RT_CPU_RATIO rlimit:
> >
> >  - a zero RLIMIT_RT_CPU_RATIO value means unlimited CPU time to that
> >RT task. If the task is not an RT task then it may not change to RT
> >priority. (i.e. a zero value makes it fully compatible with previous
> >RT scheduling semantics.)
> 
> What about root, or CAP_SYS_NICE?

what do you mean? root can change its own rlimit if it wants to, but
there is no special hack to allow root/CAP_SYS_NICE tasks to get
unlimited RT CPU time. That would make it impossible for a privileged
task to make use of this feature.

> >  - the CPU-use measurement code has a 'memory' of roughly 300 msecs.
> >I.e. if an RT task runs 100 msecs nonstop then it will increase
> >its CPU use by about 30%. This should be fast enough for users for
> >the limit to be human-inperceptible, but slow enough to allow
> >occasional longer timeslices to RT tasks.
> 
> So, at 80% I get 240 msecs out of every 300?  If I use them all up, do
> I then have to wait 60 msecs before getting scheduled again?

it's implemented as a decayling average. The 300 msecs means that if the
current RT average is at 100%, and suddenly every RT task stops running
(i.e. the average will decrease as fast as it can), then it will reach
5% in 300 msecs.

the same goes in the other direction: it needs roughly 300 msecs for the

PCI Express MSI in kernel 2.4 ?

[Philippe MARTEAU]

hello,
I saw that there is an implementation of MSI in the Linux kernel 2.6 stream.
Is there a possibility to port this in the 2.4 kernel tree (we are at 
this time using 2.4.17) ?

Is this already foreseen and planned and when ?
Is this MSI feature already used out there ? on which target processor 
and southbridge ?

Please CC me ( mailto:[EMAIL PROTECTED] )since I am not 
subscribed to the mail list.

Regards
Philippe
-
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] unexport register_cpu and unregister_cpu

[Nathan Lynch]

http://linus.bkbits.net:8080/linux-2.5/[EMAIL 
PROTECTED]|src/|src/drivers|src/drivers/base|related/drivers/base/cpu.c

This changeset introduced exports for register_cpu and unregister_cpu
right after 2.6.10.  As far as I can tell these are not called from any
code which can be built as a module, and I can't think of a good reason
why any out of tree code would use them.  Unless I've missed something,
can we remove them before 2.6.11?

Build-tested for ia64 and i386.

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>

Index: linux-2.6.11-rc2-mm1/drivers/base/cpu.c
===
--- linux-2.6.11-rc2-mm1.orig/drivers/base/cpu.c2005-01-25 
23:50:02.677255800 -0600
+++ linux-2.6.11-rc2-mm1/drivers/base/cpu.c 2005-01-25 23:56:28.436611464 
-0600
@@ -64,7 +64,6 @@
 
return;
 }
-EXPORT_SYMBOL(unregister_cpu);
 #else /* ... !CONFIG_HOTPLUG_CPU */
 static inline void register_cpu_control(struct cpu *cpu)
 {
@@ -96,9 +95,6 @@
register_cpu_control(cpu);
return error;
 }
-#ifdef CONFIG_HOTPLUG_CPU
-EXPORT_SYMBOL(register_cpu);
-#endif
 
 
 


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

Remove sched.h inclusion from module.h

[Dave Jones]

I resurrected this ancient patch I did about 9 months ago
that fell by the wayside.  module.h pulls in sched.h,
which means that anything built as a module pulls in
a zillion (mostly unneeded) include files.

When I benchmarked the difference back last year, I'm fairly
sure it was on the order of 2 minutes faster after the
untangling below. Today, I'm only able to squeeze out
a 30 second improvement on make allmodconfig. Maybe I had
less RAM back then. *shrug*.

Build tested on x86/x86-64 only, other archs will likely
need minor fixups in arch/.

Dave

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/26 00:52:17-05:00 [EMAIL PROTECTED] 
#   [INCLUDE] Remove sched.h inclusion from module.h.
#   Also move some capability bits to capability.h, and break
#   out some of sched.h to wakeup.h
#   
#   Build checked for make all modconfig,yesconfig,noconfig
#   
#   Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
# 

diff -Nru a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 
b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c   2005-01-26 01:36:57 
-05:00
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c   2005-01-26 01:36:57 
-05:00
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include/* current */
 #include 
 #include 
 #include 
diff -Nru a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 
b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c
--- a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c2005-01-26 01:36:57 
-05:00
+++ b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c2005-01-26 01:36:57 
-05:00
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include/* current / set_cpus_allowed() */
 
 #include  
 #include 
diff -Nru a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 
b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c2005-01-26 01:36:57 
-05:00
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c2005-01-26 01:36:57 
-05:00
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include/* for current / set_cpus_allowed() */
 
 #include 
 #include 
diff -Nru a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 
b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2005-01-26 01:36:57 
-05:00
+++ b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2005-01-26 01:36:57 
-05:00
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include/* current */
 #include 
 #include 
 
diff -Nru a/arch/i386/kernel/cpu/mtrr/if.c b/arch/i386/kernel/cpu/mtrr/if.c
--- a/arch/i386/kernel/cpu/mtrr/if.c2005-01-26 01:36:57 -05:00
+++ b/arch/i386/kernel/cpu/mtrr/if.c2005-01-26 01:36:57 -05:00
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define LINE_SIZE 80
diff -Nru a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c 2005-01-26 01:36:57 -05:00
+++ b/drivers/acpi/processor_idle.c 2005-01-26 01:36:57 -05:00
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include/* need_resched() */
 
 #include 
 #include 
diff -Nru a/drivers/block/paride/paride.c b/drivers/block/paride/paride.c
--- a/drivers/block/paride/paride.c 2005-01-26 01:36:57 -05:00
+++ b/drivers/block/paride/paride.c 2005-01-26 01:36:57 -05:00
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include/* TASK_* */
 
 #ifdef CONFIG_PARPORT_MODULE
 #define CONFIG_PARPORT
diff -Nru a/drivers/block/paride/pg.c b/drivers/block/paride/pg.c
--- a/drivers/block/paride/pg.c 2005-01-26 01:36:57 -05:00
+++ b/drivers/block/paride/pg.c 2005-01-26 01:36:57 -05:00
@@ -162,6 +162,8 @@
 #include 
 #include 
 #include 
+#include/* current, TASK_* */
+#include 
 
 #include 
 
diff -Nru a/drivers/block/paride/pt.c b/drivers/block/paride/pt.c
--- a/drivers/block/paride/pt.c 2005-01-26 01:36:57 -05:00
+++ b/drivers/block/paride/pt.c 2005-01-26 01:36:57 -05:00
@@ -146,6 +146,7 @@
 #include 
 #include 
 #include 
+#include/* current, TASK_*, schedule_timeout() */
 
 #include 
 
diff -Nru a/drivers/char/i8k.c b/drivers/char/i8k.c
--- a/drivers/char/i8k.c2005-01-26 01:36:57 -05:00
+++ b/drivers/char/i8k.c2005-01-26 01:36:57 -05:00
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff -Nru a/drivers/char/watchdog/cpu5wdt.c b/drivers/char/watchdog/cpu5wdt.c
--- a/drivers/char/watchdog/cpu5wdt.c   2005-01-26 01:36:57 -05:00
+++ b/drivers/char/watchdog/cpu5wdt.c   2005-01-26 01:36:57 -05:00
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff -Nru a/drivers/char/watchdog/mixcomwd.c b/drivers/char/watchdog/mixcomwd.c
--- a/drivers/char/watchdog/mixcomwd.c  2005-01-26 01:36:57 -05:00
+++ b/drivers/char/watchdog/mixcomwd.c  2005-01-26 01:36:57 -05:00
@@ -45,6 +45,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
diff 

error while recompinling linux kernel

[[EMAIL PROTECTED]]

Hi,

I am a beginer in linux. I tried to recomplile kernel 2.4.9 and I
encountered following error 

make[3]: *** [am79c961a.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/net'
make[1]: *** [_subdir_net] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2

can you someone help me please?

sudhir


mail2web - Check your email from the web at
http://mail2web.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] Use MM_VM_SIZE in exit_mmap

[Andi Kleen]

Anton Blanchard <[EMAIL PROTECTED]> writes:
>
> It is possible for one task to end up "owning" an mm from another - we
> have seen this with the procfs code when process 1 accesses
> /proc/pid/cmdline of process 2 while it is exiting.  Process 2 exits
> but does not tear its mm down. Later on process 1 finishes with the proc
> file and the mm gets torn down at this point.

IMHO that's the root bug. That sounds really dangerous and will likely
cause other problems because it is totally unexpected. How about fixing
/proc to not do this?

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

Re: [PATCH] Russian encoding support for MacHFS

[Pavel Fedin]

On Tue, 25 Jan 2005 16:34:57 +0100 (CET)
Roman Zippel <[EMAIL PROTECTED]> wrote:

> I'm not quite sure, what problem you're trying to solve here.

 I am trying to implement character sets conversion for MacHFS. I have some CD 
s with russian file names. Currently they are not displayed properly because 
Linux uses KOI8-R character set for russian letters and Macintosh uses its own 
character set called Mac-cyrillic or codepage 10007.
 Firstly i tried to implement character set conversion using NLS tables. It was 
done using "iocharset" and "codepage" arguments. "Iocharset" specified Linux's 
local character set and "codepage" specified HFS's character set. So to convert 
a character i needed to process it twice: convert from "codepage" to Unicode 
and then convert from Unicode to "iocharset".
 The problem with this is that some characters will be lost during this 
conversion. Not all characters from source ("codepage") charset are present in 
destination ("iocharset") charset table (for example "Folder" sign). But for 
proper operation of dir.c/hfs_lookup() function we need to be able to convert 
the name back from KOI8-R to CP10007 otherwise searching algorythm will fail. 
This will lead to that we won't be able to operate with any file which contains 
such a characters.
 A solution was to use my own conversion table which ensures that no characters 
will be lost during conversion in both directions. Every unique source 
character is translated to some unique destination character. Of course 
Mac-specific characters are not displayed properly but they're not lost either. 
"codepage" argument was omitted for simplicity because specific "iocharset" 
implies specific "codepage" (for example if iocharset is koi8-r then we can 
assume that Macintosh codepage is mac-cyrillic). But some people said that this 
patch can't be approved because not using NLS is bad solution. So i'd like to 
talk to you, may be we'll find a better solution (because you know HFS better 
than me) or we can come to a conclusion that there is really no solution and 
push the patch upstream.

> If you want to store unicode characters use HFS+, I plan to implement nls 
> support real soon for it (especially because to also fix the missing 
> decomposition support). 

 Would be nice. I also thought about it but i have no HFS+ disks with russian 
names so i can't test it. And i decided not to do a "blind" implementation in 
order not to break the filesystem. Currently my patch adds "iocharset" 
argumnent to HFS+ also (so that i can specify both filesystems in one 
/etc/fstab line, this is useful for CD-ROM) but it is ignored there.

-- 
Best regards,
Pavel Fedin,
mailto:[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/

[PATCH] irq_affinity: fix build when CONFIG_PROC_FS=n

[Randy.Dunlap]

Need 'irq_affinity' array when CONFIG_PROC_FS=n.
With CONFIG_PROC_FS=n, the irq_affinity[NR_IRQS] array
is not available in arch/i386/kernel code:
arch/i386/kernel/built-in.o(.text+0x10037): In function `do_irq_balance':
: undefined reference to `irq_affinity'
arch/i386/kernel/built-in.o(.text+0x101a9): In function `do_irq_balance':
: undefined reference to `irq_affinity'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
 kernel/irq/manage.c |2 ++
 kernel/irq/proc.c   |2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp ./kernel/irq/proc.c~irq_affinity ./kernel/irq/proc.c
--- ./kernel/irq/proc.c~irq_affinity	2004-12-24 13:34:29.0 -0800
+++ ./kernel/irq/proc.c	2005-01-25 20:53:45.581952208 -0800
@@ -19,8 +19,6 @@ static struct proc_dir_entry *root_irq_d
  */
 static struct proc_dir_entry *smp_affinity_entry[NR_IRQS];
 
-cpumask_t irq_affinity[NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_ALL };
-
 static int irq_affinity_read_proc(char *page, char **start, off_t off,
   int count, int *eof, void *data)
 {
diff -Naurp ./kernel/irq/manage.c~irq_affinity ./kernel/irq/manage.c
--- ./kernel/irq/manage.c~irq_affinity	2004-12-24 13:35:50.0 -0800
+++ ./kernel/irq/manage.c	2005-01-25 20:54:09.753277608 -0800
@@ -15,6 +15,8 @@
 
 #ifdef CONFIG_SMP
 
+cpumask_t irq_affinity[NR_IRQS] = { [0 ... NR_IRQS-1] = CPU_MASK_ALL };
+
 /**
  *	synchronize_irq - wait for pending IRQ handlers (on other CPUs)
  *

porting Linux to a virtual machine

[Robert W. Fuller]

Has anybody ported Linux to a virtual machine?  Does anybody have any 
pointers aside from the lkml's abbreviated FAQ entry concering porting 
to a new processor?  What would be the best way of going about this?  Is 
there a supported architecture that is simpler than the others and/or 
better to use as a model?  What about the UML (User Mode Linux) 
architecture?  Are there doc's, FAQ's, etc. concerning this?   Should I 
just read the mailing list and harvest the source code?  Thank you for 
any (positive) input.
-
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-rc2] modules: add version and srcversion to sysfs

[Matt Domsch]

Module:  Add module version and srcversion to the sysfs tree

There are two ways one could go with this:
1) strdup() the interesting fields from modinfo section before it is discarded.
That's what this patch does, and what Greg's original patch did too,
despite his reservations about using strdup().
2) don't drop the modinfo section on load, and use those strings directly.

The problem with 2) is that the modinfo section can be quite large,
compared to the few bytes that the "interesting" fields consume.  And
it would have to be kmalloc'd and copied from the vmalloc area before
that area is dropped.

So, I did #1.

It's trivial to add new fields now.  For my purposes, version and
srcversion are all I need, so that's all I'm exposing via sysfs.
Others may be added later as needed.

As the idea originated from GregKH, I leave his Signed-off-by: intact,
though the implementation is nearly completely new.  Compiled and run
on x86_64.

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>

Rusty, thoughts?

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= include/linux/module.h 1.92 vs edited =
--- 1.92/include/linux/module.h 2005-01-10 13:28:15 -06:00
+++ edited/include/linux/module.h   2005-01-25 22:25:15 -06:00
@@ -51,6 +51,9 @@ struct module_attribute {
 ssize_t (*show)(struct module_attribute *, struct module *, char *);
 ssize_t (*store)(struct module_attribute *, struct module *,
 const char *, size_t count);
+   void (*setup)(struct module *, const char *);
+   int (*test)(struct module *);
+   void (*free)(struct module *);
 };
 
 struct module_kobject
@@ -249,6 +252,8 @@ struct module
/* Sysfs stuff. */
struct module_kobject mkobj;
struct module_param_attrs *param_attrs;
+   const char *version;
+   const char *srcversion;
 
/* Exported symbols */
const struct kernel_symbol *syms;
= kernel/module.c 1.132 vs edited =
--- 1.132/kernel/module.c   2005-01-11 18:42:57 -06:00
+++ edited/kernel/module.c  2005-01-25 23:42:17 -06:00
@@ -663,6 +663,57 @@ static struct module_attribute refcnt = 
.show = show_refcnt,
 };
 
+static char *strdup(const char *str)
+{
+   char *s;
+
+   if (!str)
+   return NULL;
+   s = kmalloc(strlen(str)+1, GFP_KERNEL);
+   if (!s)
+   return NULL;
+   strcpy(s, str);
+   return s;
+}
+
+#define MODINFO_ATTR(field)\
+static void setup_modinfo_##field(struct module *mod, const char *s)  \
+{ \
+   mod->field = strdup(s);   \
+} \
+static ssize_t show_modinfo_##field(struct module_attribute *mattr,   \
+   struct module *mod, char *buffer) \
+{ \
+   return sprintf(buffer, "%s\n", mod->field);   \
+} \
+static int modinfo_##field##_exists(struct module *mod)   \
+{ \
+   return mod->field != NULL;\
+} \
+static void free_modinfo_##field(struct module *mod)  \
+{ \
+kfree(mod->field);\
+mod->field = NULL;\
+} \
+static struct module_attribute modinfo_##field = {\
+   .attr = { .name = __stringify(field), .mode = 0444,   \
+ .owner = THIS_MODULE }, \
+   .show = show_modinfo_##field, \
+   .setup = setup_modinfo_##field,   \
+   .test = modinfo_##field##_exists, \
+   .free = free_modinfo_##field, \
+};
+
+
+MODINFO_ATTR(version);
+MODINFO_ATTR(srcversion);
+
+static struct module_attribute *modinfo_attrs[] = {
+   _version,
+   _srcversion,
+   NULL,
+};
+
 #else /* !CONFIG_MODULE_UNLOAD */
 static void print_unload_info(struct seq_file *m, struct module *mod)
 {
@@ -1031,6 +1082,29 @@ static void module_remove_refcnt_attr(st
 }
 #endif
 
+static int module_add_modinfo_attrs(struct module *mod)
+{
+   struct module_attribute * attr;
+   int error = 0;
+   int i;
+
+   for (i = 0; (attr = modinfo_attrs[i]) && 

Re: Problem with cpu_rest() change

[Kumar Gala]

Will these changes cause us to back out the patch already made to 
arch/ppc/kernel/idle.c for systems that did not support powersavings?

- kumar
On Jan 25, 2005, at 5:49 PM, Benjamin Herrenschmidt wrote:
On Tue, 2005-01-25 at 10:01 +0100, Ingo Molnar wrote:
> it can be bad for the idle task to hold the BKL and to have 
preemption
 > enabled - in such a situation the scheduler will get confused if an
 > interrupt triggers a forced preemption in that small window. But 
it's
 > not necessary to keep IRQs disabled after the BKL has been dropped. 
In
 > fact i think IRQ-disabling doesnt have to be done at all, the patch
 > below ought to solve this scenario equally well, and should solve 
the
 > PPC side-effects too.
 >
> Tested ontop of 2.6.11-rc2 on x86 PREEMPT+SMP and PREEMPT+!SMP (which
 > IIRC were the config variants that triggered the original problem), 
on
 > an SMP and on a UP system.

Excellent, thanks.
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/
-
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-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Jack O'Quin]

Ingo Molnar <[EMAIL PROTECTED]> writes:

> pretty much the only criticism of the RT-CPU patch was that the global
> sysctl is too rigid and that it doesnt allow privileged tasks to ignore
> the limit. I've uploaded a new RT-CPU-limit patch that solves this
> problem:
>
>   http://redhat.com/~mingo/rt-limit-patches/
>
> i've removed the global sysctl and implemented a new rlimit,
> RT_CPU_RATIO: the maximum amount of CPU time RT tasks may use, in
> percent. For testing purposes it defaults to 80%.

Small terminology quibble: `ratio' sounds like a fraction, not a
percentage.  Since it really is a percentage, why not call it
RLIMIT_RT_CPU_PERCENT, or (maybe better) just RLIMIT_RT_CPU?

Does getrusage() return anything for this?  How can a field be added
to the rusage struct without breaking binary compatibility?  Can we
assume that no programs ever use sizeof(struct rusage)?

> the RT-limit being an rlimit makes it much more configurable: root tasks
> can have unlimited CPU time limit, while users could have a more
> conservative setting of say 30%. This also makes it per-process and
> runtime configurable as well. The scheduler will instantly act upon any
> new RT_CPU_RATIO rlimit.

I'm having trouble coming up with reasons why this is better than the
previous (rt_cpu_limit) solution, which was so much simpler and easier
to explain.

I can imagine defining per-user limits based on membership in groups
like `audio', `video' or `cdrom'.  While logical, I'm having trouble
thinking of usage scenarios where it makes any practical difference.

What problem(s) are we trying to solve with this rlimits field?

> multiple tasks can have different rlimits as well, and the scheduler
> interprets it the following way: it maintains a per-CPU "RT CPU use"
> load-average value and compares it against the per-task rlimit. If e.g. 
> the task says "i'm in the 60% range" and the current average is 70%,
> then the scheduler delays this RT task - if the next task has an 80%
> rlimit then it will be allowed to run. This logic is straightforward and
> can be used as a further control mechanism against runaway highprio RT
> tasks.

I can almost understand how this works, but not quite.  I guess I need
to read the code.  You're trying to selectively throttle certain tasks
and not others, right?  But, the limit they're hitting is system
global.

My main conceptual difficulty is driven by the fact that "realtime" is
actually a system attribute.  Factors such as hardware, kernel, device
drivers, applications, and system configuration all contribute to it
and can all screw it up.

So, what does it mean for a task to say "I'm in the 60% range"?  That
it individually will never use more than 60% of any one CPU?  Or, that
it and several other associated tasks will never use more than that?

> other properties of the RT_CPU_RATIO rlimit:
>
>  - a zero RLIMIT_RT_CPU_RATIO value means unlimited CPU time to that
>RT task. If the task is not an RT task then it may not change to RT
>priority. (i.e. a zero value makes it fully compatible with previous
>RT scheduling semantics.)

What about root, or CAP_SYS_NICE?

>  - the CPU-use measurement code has a 'memory' of roughly 300 msecs.
>I.e. if an RT task runs 100 msecs nonstop then it will increase
>its CPU use by about 30%. This should be fast enough for users for
>the limit to be human-inperceptible, but slow enough to allow
>occasional longer timeslices to RT tasks.

So, at 80% I get 240 msecs out of every 300?  If I use them all up, do
I then have to wait 60 msecs before getting scheduled again?
-- 
  joq
-
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/

Software Suspend for 2.4 Final Release

[Nigel Cunningham]

Hi everyone.

SoftwareSuspend 2.1.5.7B for the 2.4.28 kernel is now available from
softwaresuspend.berlios.de.

Bug fixes and forward ports to 2.4.29 and later kernels notwithstanding,
it is intended to be the last release of SoftwareSuspend for the 2.4
series kernels.

The 2.4 version of Suspend is generally pretty easily to get going, but
if you have any questions or problems, you will find lots of resources
at softwaresuspend.berlios.de. In particular, there are HOWTOs, FAQs,
and a Wiki that you can consult before asking on the mailing lists
you'll also find there.

Fuller instructions regarding applying the package can be found in the
README file, included in the package.

Nigel
-- 
Nigel Cunningham
Software Engineer
Cyclades Corporation

http://cyclades.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.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Jack O'Quin]

Ingo Molnar <[EMAIL PROTECTED]> writes:

> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>
>> At around 55 seconds into the run, JACK got in trouble and throttled
>> itself back to approximately the 30% limit (actually a little above).
>> Then, around second 240 it got in trouble again, this time collapsing
>> completely.  I'm a bit confused by all the messages in that log, but
>> it appears that approximately 9 of the 20 clients were evertually shut
>> down by the JACK server.  It looks like the second collapse around 240
>> also caused the scheduler to revoke RT privileges for the rest of the
>> run (just a guess).
>
> no, the scheduler doesnt revoke RT privileges, it just 'delays' RT tasks
> that violate the threshold. In other words, SCHED_OTHER tasks will have
> a higher effective priority than RT tasks, up until the CPU use average
> drops below the limit again.

When does it start working again?  Does it continue getting 80% of
each CPU in the long run?  What is the period over which this "delay"
occurs and recurs?

I know how to deal with running out of CPU cycles.  This seems to
present a new and different failure mode.  I'd like to know that I can
have 80% of the cycles for each realtime period.  (For JACK this is
determined by the audio buffer size.)  If I can't finish my work in
that allotment, then I've failed and need to scale back.

But, the scheduler doesn't know about realtime cycles.  It just knows
that I used more than 80% over some unspecified period.  So, maybe I
handled the first 8 audio buffers, but have no cycles left for buffers
9 and 10.  Is that right?  That's not a situation I currently expect
to deal with.  I need to figure out how to handle it.

> the effect is pretty similar to starting too many Jack clients - things
> degrade quickly and _all_ clients start skipping, and the whole audio
> experience escallates into a big xrun mess. Not much to be done about it
> i suspect. Maybe if the current 'RT load' was available via /proc then
> jackd could introduce some sort of threshold above which it would reject
> new clients?

It could.  

It also kicks clients out of the realtime graph if they take too long.

>> JACK can probably do a better job of shutting down hyperactive
>> realtime clients than the kernel, because it knows more about what the
>> user is trying to do.  Multiplying incomprehesible rlimits values does
>> not help much that I can see.
>
> please debug this some more - the kernel certainly doesnt do anything
> intrusive - the clients only get delayed for some time.

One simple definition of a realtime operation: there exists some
deadline beyond which, if you didn't get the job done, you might as
well not do it at all.

For many applications, it might actually be less intrusive to kill
them than to delay them.  My first thought is to revoke SCHED_FIFO and
send a signal.  The default action could be process termination, but
the process might optionally catch the signal, throttle back and try
to restart the operation.

Maybe there are other usage scenarios for which delaying the realtime
thread is a good idea.  What kind did you have in mind?

>> Sometimes musicians want to "push the envelope" using CPU-hungry
>> realtime effects like reverbs or Fourier Transforms.  It is often hard
>> to predict how much of this sort of load a given system can handle.
>> JACK reports its subsystem-wide "DSP load" as a moving average,
>> allowing users to monitor it.  It might be helpful if the kernel's
>> estimate of this number were also available somewhere (but maybe that
>> value has no meaning to users).  Often, the easiest method is to push
>> things to the breaking point, and then back off a bit.
>
> yeah, i'll add this to /proc, so that utilities can access it. Jackd
> could monitor it and refuse to start new clients if the RT load is
> dangerously close to the limit (say within 10% of it)?

That could be useful.  But, isn't it per-CPU?  

Would this be a composite value?  Average?  Does that mean anything?

>> The equivalent rlimits experiment probably requires:
>> 
>>   (1) editing /etc/security/limits.conf
>>   (2) shutting everything down
>>   (3) logout
>>   (4) login
>>   (5) restarting the test
>
> well, there's setrlimit, so you could add a jackd client callback that
> instructs all clients to change their RT_CPU_RATIO rlimit. In theory we
> could try to add a new rlimit syscall that changes another task's rlimit
> (right now the syscalls only allow the changing of the rlimit of the
> current task) - that would enable utilities to change the rlimit of all
> tasks in the system, achieving the equivalent of a global sysctl.

Sure, we could.  That does seem like an enormously complicated
mechanism to accomplish something so simple.  We are taking a global
per-CPU limit, treating it as if it were per-process, then invoking a
complex callback scheme to propagate new values, all just to shoe-horn
it into the rlimits structure.

There are many problems for which rlimits is a 

fresh Nude old little old preteens look

[Carol Cordero]

Allow me :) Please :)

Youngest, perfect wish and most popular models inside. 

In the name of Hypocrites, doctors have invented the most exquisite 
form of torture ever known to man: survival.
http://www.geocities.com/angelica_lewis_10/?s=umc=YbWPM-ZfSWfY.OdfS,ZfSWfY,VSd

Lolitas are always they too pure, fresh and horny and and by the way - you are 
the one drive they always wanted to meet. 

The quantity of books in a person's library, is often a cloud of 
witnesses to the ignorance of the owner.
You will see conviviality the most frank moments

Only a generation of readers will span a generation of writers.


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

Re: 2.6.11-rc2-mm1

[Dmitry Torokhov]

On Tuesday 25 January 2005 16:14, Evgeniy Polyakov wrote:
> On Tue, 25 Jan 2005 11:11:42 -0500
> Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2005-01-25 at 14:23 +, Christoph Hellwig wrote:
> > > > > > +static void pc8736x_fini(void)
> > > > > > +{
> > > > > > + sc_del_sc_dev(_dev);
> > > > > > +
> > > > > > + while (atomic_read(_dev.refcnt)) {
> > > > > > + printk(KERN_INFO "Waiting for %s to became free: 
> > > > > > refcnt=%d.\n",
> > > > > > + pc8736x_dev.name, 
> > > > > > atomic_read(_dev.refcnt));
> > > > > > +
> > > > > > + set_current_state(TASK_INTERRUPTIBLE);
> > > > > > + schedule_timeout(HZ);
> > > > > > +
> > > > > > + if (current->flags & PF_FREEZE)
> > > > > > + refrigerator(PF_FREEZE);
> > > > > > +
> > > > > > + if (signal_pending(current))
> > > > > > + flush_signals(current);
> > > > > > + }
> > > > > > +}
> > > > > >
> > > > > > And who gurantess this won't deadlock?  Please use a dynamically 
> > > > > > allocated
> > > > > > driver model device and it's refcounting, thanks.
> > > > >
> > > > > Sigh.
> > > > >
> > > > > Christoph, please read the code before doing such comments.
> > > > > I very respect your review and opinion, but only until you respect
> > > > > others.
> > > >
> > > > The code above pretty much means you can keep rmmod stalled forever.
> > > 
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > through superio core and remove it's module on other CPU, above loop
> > > will wait untill all reference counters are dropped.
> > 
> > I have a slightly different concern - the superio is a completely new
> > subsystem and it should be integtrated with the driver model
> > ("superio" bus?). Right now it looks like it is reimplementing most of
> > the abstractions (device lists, driver lists, matching, probing).
> > Moving to driver model significatntly affects lifetime rules for the
> > objects, etc. etc. and will definitely not allow code such as above.
> > 
> > It would be nice it we get things right from the start.
> 
> bus model is not good here - we need bus in each logical device and
> bus in each superio chip(or at least second case).
> Each bus bus have some crosslinking to devices in other buses, 
> and each new device
> must be checked in each bus and probably added to each device...
> 
> It is not like I see it.
> 
> Consider folowing example: 
> each device from set A belongs to each device from set B.
> n <-> n, it is not the case when one bus can handle all features.
> 
> That is why I did not use driver model there.
> It is specific design feature, which is proven to work.
>

Ok, I briefly looked over the patches and that is what I understand
(please correct me where I am wrong):

- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages
  (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual
  superio interfaces and provide unified userspace interface that allows
  reading, writing and analog of ioctl.

So the question is why you can't have superio bus where superio chips
register their individual interfaces as individual devices. gpio, acb, etc
are drivers that bind to superio devices and create class devices gpio.

You could have:

sys
|-bus
| |-superio
| | |-devices
| | | |-sio0 -> ../../../devices/pci:00/:00:1e.0/:02:03.0/sio0
| | | |-sio1 -> ../../../devices/pci:00/:00:1e.0/:02:03.0/sio1
| | | |-sio2 -> ../../../devices/pci:00/:00:1e.0/:02:04.0/sio2
| | |-drivers
| | | |-gpio
| | | | |-sio1 -> ../../../../devices/pci:00/:00:1e.0/:02:03.0/sio1
| | | | |-sio2 -> ../../../../devices/pci:00/:00:1e.0/:02:04.0/sio2
| | | |-acb
| | | | |-sio0 -> ../../../../devices/pci:00/:00:1e.0/:02:03.0/sio0
|
|-class
| |-gpio
| | |-gpio0
| | |-gpio1

gpioX have control and data attributes that allow reading and writing...

Am I missing something?

-- 
Dmitry
-
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: fix use kref for device_node refcounting

[Nathan Lynch]

On Mon, 2005-01-24 at 02:15 -0800, Andrew Morton wrote:
> ppc64-use-kref-for-device_node-refcounting.patch
>   ppc64: use kref for device_node refcounting

This introduced an unbalanced get/put in of_add_node which would cause
newly-added device nodes to be prematurely freed.  Sorry for the
screwup, a more rigorously tested fix follows.

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>


---


diff -puN arch/ppc64/kernel/prom.c~fix-kref-devnode arch/ppc64/kernel/prom.c
--- linux-2.6.11-rc2-mm1/arch/ppc64/kernel/prom.c~fix-kref-devnode  
2005-01-25 21:10:50.0 -0600
+++ linux-2.6.11-rc2-mm1-nathanl/arch/ppc64/kernel/prom.c   2005-01-25 
21:14:02.0 -0600
@@ -1771,6 +1771,7 @@ int of_add_node(const char *path, struct
np->properties = proplist;
OF_MARK_DYNAMIC(np);
kref_init(>kref);
+   of_node_get(np);
np->parent = derive_parent(path);
if (!np->parent) {
kfree(np);

_


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

Banging my head on SATA / ATAPI DMA problem. Help?

[Rick Bressler]

I've played with a lot of hardware since the Linux 1.0.9 days but not
yet run into something quite like this.  Alan has been talking a lot
lately about ATA/SATA patches, and while I mostly lurk on this list,
thought this one might be interesting enough for somebody to give me
some advice.

A friend of mine won an IBM 8482-2RU at Linux World last year and he is
trying to get it working with a 2.6.x kernel.

The problem I'm unable to resolve is that his primary drive, a Seagate
ST3160023AS (SATA) works fine in DMA mode, but whenever it is plugged
in, he can't get his PLEXTOR PX-716A DVD/CD-RW (PATA) to come up in DMA
mode.  (Works in PIO mode.)

At first I was wondering if it wasn't a BIOS setting (legacy mode ATA
etc) but he swears he can't find anything like that in his BIOS.  (He's
on the latest BIOS that IBM has for the box.)

He's in California and I'm in Washington so I have to take his word for
it.

hdparm says the DVD/CD can do DMA, and in theory is being configured by the
BIOS

DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4

The kernel doesn't detect it.  It can't be turned on manually with
hdparm.  If the hard drive is unplugged, I note that it is recognizes
the CD as as being on an ICH5 chipset, but it doesn't seem to identify
it as such with the hard drive plugged in.  Odd hardware?  Strange
hardware detection?  Something subtle in the kernel config that I keep
missing?  (BLK_DEV_PIIX is turned on.)

Both drives come up DMA on 2.4.x (no libata). but no 2.6 kernel we've
tried (2.6.6, 2.6.9, 2.6.10 2.6.10-ac10) seems to be able to manage it.

I've been working with him for a couple of weeks, but have exhausted my
luck on Google, list archives etc. and decided it is time to see if
anybody can give me some ideas on how to proceed.  Maybe it is just
flakey hardware...

Any help, pointers or suggestions  that you may care to offer would be
appreciated.

I monitor the list (in nightly batch mode) so feel free to reply any way
you like, list or email...

Thanks in advance.

His PCI layout:

# lspci
:00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub (rev 
02)
:00:03.0 PCI bridge: Intel Corp. 82875P/E7210 Processor to PCI to CSA 
Bridge (rev 02)
:00:1c.0 PCI bridge: Intel Corp. 6300ESB 64-bit PCI-X Bridge (rev 02)
:00:1d.0 USB Controller: Intel Corp. 6300ESB USB Universal Host Controller 
(rev 02)
:00:1d.1 USB Controller: Intel Corp. 6300ESB USB Universal Host Controller 
(rev 02)
:00:1d.4 System peripheral: Intel Corp. 6300ESB Watchdog Timer (rev 02)
:00:1d.5 PIC: Intel Corp. 6300ESB I/O Advanced Programmable Interrupt 
Controller (rev 02)
:00:1d.7 USB Controller: Intel Corp. 6300ESB USB2 Enhanced Host Controller 
(rev 02)
:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 0a)
:00:1f.0 ISA bridge: Intel Corp. 6300ESB LPC Interface Controller (rev 02)
:00:1f.2 IDE interface: Intel Corp. 6300ESB SATA Storage Controller (rev 02)
:00:1f.3 SMBus: Intel Corp. 6300ESB SMBus Controller (rev 02)
:02:01.0 Ethernet controller: Intel Corp. 82547GI Gigabit Ethernet 
Controller
:03:04.0 SCSI storage controller: Adaptec AIC-7901 U320 (rev 10)
:04:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
[Radeon 7000/VE]
:04:08.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 
10)

A boot from a Knoppix CD with the hard drive unplugged yielded a working
DMA enabled CDROM with a 2.6.9 kernel.

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot :00:1f.1
ACPI: PCI interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive

Bits of dmesg for the failure case:

No DMA on CD-ROM with hd plugged in

Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive
ide1: I/O resource 0x170-0x177 not free.
ide1: ports already in use, skipping probe
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache
Uniform CD-ROM driver Revision: 3.20

The SATA drive comes up fine.

libata version 1.10 loaded.
ata_piix version 1.03
ata_piix: combined mode detected
ACPI: PCI interrupt :00:1f.2[A] -> GSI 18 (level, low) -> IRQ 18
ata: 0x1f0 IDE port busy
PCI: Setting latency timer of device :00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 312581808 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
  Vendor: ATA   Model: ST3160023AS   Rev: 3.18
  Type:   Direct-Access  ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte 

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 16:34 -0800, Christoph Lameter wrote:

> I just hope that the implementation of one arch does not become a standard
> without sufficient reflection. Could we first get an explanation of
> the rationale of the offsets? From my viewpoint of the ia64 implementation
> I have some difficulty understanding why such complicated things as
> prescale and postscale are necessary in gettimeday and why the simple
> formula that we use in gettimeofday is not sufficient?

What is complicated here ? The formula, at least as we do on ppc64, is
simply:

 time = (hw_value - prescale offset) / scale + post scale offset

Please, don't tell me that a substraction bothers you for performances,
and this first offset, while it could maybe be "folded" into the second
one, is actually handy, especially since it allows you to keep the
(hw_value - prescale offset) in a 32 bits number if your HW timebase
isn't too fast.

Now, for the details, on ppc, we calculate time in what we call "xsecs"
which is 2^20 xsec/sec, so not exactly micro or nanoseconds, but that's
also for simplifying calculations, we may want the generic code to just
fallback on to ns.
  
> Frankly, the direction that the design of the new time subsystem is
> taking is bothering me. Work on this on our part would just improve the
> situation from drastically worse performance to somewhat worse. So far I
> have not seen a benefit of moving away from the existing code base. For
> the project to make sense it needs at least to be evident that the design
> of the solution would lead to better timer performance in the long run.
> Conceptually that seems so far not to be possible.

The main problem with performances in the new code is the fact that it
does the ntp correction on every call. John is aware that it is a
problem and will fix that.

> I'd love simplication of the timer subsystem through the use of
> nanosecond offsets. However, the POSIX api always has extra fields
> for seconds and nanoseconds and converting back and forth between the
> internal representation in 64bit nanoseconds and the POSIX structures may
> be another performance penalty since it involves divisions and remainder
> processing.
> 
> What I think is a priority need is some subsystem that manages
> time sources effectively (including the ability of the ntp code to
> scale the appropriately) and does that in an arch independent
> way so that all the code can be consolidated. Extract the best existing
> solutions and work from there.

Which is what John is trying to do, so help instead of criticizing :)

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: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 16:17 -0800, john stultz wrote:

> Hmm. In my code, I move the interval delta (similar to your pre-scale
> offset) to system_time (seems to be equivalent to the post-scale) at
> each call to timeofday_interrupt_hook(). So while 64 bits are normally
> used, you could probably get away doing the interval delta calculations
> in 32bits if your timesource frequency isn't too large. This would only
> be done in the arch-specific 32bit vsyscall code, right?

Yes. Looks ok so far, but I need to make sure by looking at the code.
I'll let you know.

> > > I still want to support vsyscall gettimeofday, although it does have to
> > > be done on an arch-by-arch basis. It's likely the systemcfg data
> > > structure can still be generated and exported. I'll look into it and see
> > > what can be done.
> > 
> > Well, since it only contains the prescale and postscale offsets and the
> > scaling value, it only needs to be updated when they change, so a hook
> > here would be fine.
> 
> Great, thats what I was hoping.
> 
> thanks
> -john
-- 
Benjamin Herrenschmidt <[EMAIL PROTECTED]>

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

Re: make flock_lock_file_wait static

[Andrew Morton]

"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
>  So, could the exports for the following symbols from the list please be
>  retained through December 31, 2005?
> 
>   blk_get_queue
>   sock_setsockopt
>   vfs_follow_link
>   __read_lock_failed
>   __write_lock_failed

I don't think there's any plan to unexport any of these, and in most cases
it would be a dopey thing to do anyway.  And if we _were_ to try to remove
any of the above exports we should go through the
feature-removal-schedule.txt process.

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

Re: 2.6.11-rc2-mm1

[William Lee Irwin III]

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

Someone who sent you a patch needs to learn how to use grep(1). There are
18 patches listed by grep -l it_timer patches/*; giving up.


-- wli

drivers/char/mmtimer.c: In function `reschedule_periodic_timer':
drivers/char/mmtimer.c:423: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:435: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_interrupt':
drivers/char/mmtimer.c:471: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_tasklet':
drivers/char/mmtimer.c:508: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:516: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_create':
drivers/char/mmtimer.c:527: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_del':
drivers/char/mmtimer.c:538: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:539: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:547: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:548: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_get':
drivers/char/mmtimer.c:561: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:569: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:570: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_set':
drivers/char/mmtimer.c:643: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:644: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:645: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:646: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:652: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:655: error: structure has no member named `it_timer'
make[4]: *** [drivers/char/mmtimer.o] Error 1
make[3]: *** [drivers/char] Error 2
make[2]: *** [drivers] Error 2
make[2]: *** Waiting for unfinished jobs
-
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] Onboard Ethernet Pro 100 on a SMP box: a very strange errors

[Denis Zaitsev]

On Tue, Jan 25, 2005 at 11:19:11PM +0200, Denis Vlasenko wrote:
> 
> Something corrupts packets. It can be sending NIC, switch in the middle,
> or receiving NIC.

Changing the receiving card closes the question.  Doesn't it 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/

[PATCH 2.6] Fix mincore cornercases: overflow caused by large "len"

[Jin, Gordon]

This patch fixes 2 cornercases of overflow caused by argument len in
sys_mincore():

Case 1: len is so large that will overflow to 0 after page alignment.
E.g. len=(size_t)(-1), i.e. 0xff...ff.
Expected result: it's overflow and return ENOMEM.
Current result: len is aligned to 0, then treated the same as len=0 and
return succeed.
This cornercase has been fixed in do_mmap_pgoff(), and here
sys_mincore() also needs this fix.

Case 2: len is a large number but will not overflow after alignment. But
start+len will overflow.
E.g. len=(size_t)(-PAGE_SIZE), and start>0.
Expected result: it's overflow and return ENOMEM.
Current result: return EINVAL. Looks like considering len as a
non-positive value, probably influenced by manpage. But since the type
of len is size_t, i.e. unsigned, it shouldn't be considered as
non-positive value.
I've also reported this inconsistency to manpage mincore.

Signed-off-by: Gordon Jin <[EMAIL PROTECTED]>

Index: linux-2.6.10/mm/mincore.c
===
--- linux-2.6.10.orig/mm/mincore.c  2005-01-12 06:59:09.0 +0800
+++ linux-2.6.10/mm/mincore.c   2005-01-18 17:29:34.432160185 +0800
@@ -97,8 +97,7 @@ static long mincore_vma(struct vm_area_s
  * return values:
  *  zero- success
  *  -EFAULT - vec points to an illegal address
- *  -EINVAL - addr is not a multiple of PAGE_CACHE_SIZE,
- * or len has a nonpositive value
+ *  -EINVAL - addr is not a multiple of PAGE_CACHE_SIZE
  *  -ENOMEM - Addresses in the range [addr, addr + len] are
  * invalid for the address space of this process, or
  * specify one or more pages which are not currently
@@ -114,13 +113,18 @@ asmlinkage long sys_mincore(unsigned lon
int unmapped_error = 0;
long error = -EINVAL;
 
+   if (!len)
+   return 0;
+
down_read(>mm->mmap_sem);
 
if (start & ~PAGE_CACHE_MASK)
goto out;
+
+   error = -ENOMEM;
len = (len + ~PAGE_CACHE_MASK) & PAGE_CACHE_MASK;
end = start + len;
-   if (end < start)
+   if (end <= start)   /* overflow */
goto out;
 
error = -EFAULT;


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

Unexpected I/O APIC on i386 2.4.29 / Tyan Thunder K8W (S2885)

[Philippe Troin]

Philippe Troin <[EMAIL PROTECTED]> writes:

[Please CC me on the replies]

This is seen on a dual-242 set-up with 2 GB of RAM running a i386
kernel (not x86_64).
2.4.27 and 2.4.28 also showed the problem.

Enclosed is the dmesg log and the lspci -vvv output.

Configuration available upon request (if it makes a difference).

Phil.

Linux version 2.4.29 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002 (Debian 
prerelease)) #1 SMP Mon Jan 24 12:48:51 PST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 7000 (ACPI data)
 BIOS-e820: 7000 - 8000 (ACPI NVS)
 BIOS-e820: ff78 - 0001 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
hm, page 000ff000 reserved twice.
hm, page 0010 reserved twice.
hm, page 000fa000 reserved twice.
hm, page 000fb000 reserved twice.
On node 0 totalpages: 524272
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 294896 pages.
ACPI: RSDP (v002 ACPIAM) @ 0x000f6a50
ACPI: XSDT (v001 A M I  OEMXSDT  0x09000423 MSFT 0x0097) @ 0x7fff0100
ACPI: FADT (v001 A M I  OEMFACP  0x09000423 MSFT 0x0097) @ 0x7fff0281
ACPI: MADT (v001 A M I  OEMAPIC  0x09000423 MSFT 0x0097) @ 0x7fff0380
ACPI: OEMB (v001 A M I  OEMBIOS  0x09000423 MSFT 0x0097) @ 0x7040
ACPI: SRAT (v001 A M I  OEMSRAT  0x09000423 MSFT 0x0097) @ 0x7fff3be0
ACPI: HPET (v001 A M I  OEMHPET  0x09000423 MSFT 0x0097) @ 0x7fff3cd0
ACPI: ASF! (v001 AMIASF AMDSTRET 0x0001 INTL 0x02002026) @ 0x7fff3d10
ACPI: DSDT (v001  0 0001 0x0001 INTL 0x02002026) @ 0x
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 Unknown CPU [15:5] APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 Unknown CPU [15:5] APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec0] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, IRQ 0-23
ACPI: IOAPIC (id[0x03] address[0xff4fe000] global_irq_base[0x18])
IOAPIC[1]: Assigned apic_id 3
IOAPIC[1]: apic_id 3, version 17, address 0xff4fe000, IRQ 24-27
ACPI: IOAPIC (id[0x04] address[0xff4ff000] global_irq_base[0x1c])
IOAPIC[2]: Assigned apic_id 4
IOAPIC[2]: apic_id 4, version 17, address 0xff4ff000, IRQ 28-31
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Using ACPI (MADT) for SMP configuration information
Kernel command line: vga=0xfffe ramdisk=0 root=/dev/discs/disc0/part1 ro
Initializing CPU#0
Detected 1592.948 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 3178.49 BogoMIPS
Memory: 2069576k/2097088k available (1313k kernel code, 27124k reserved, 554k 
data, 108k init, 1179584k highmem)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 131072 (order: 7, 524288 bytes)
Page-cache hash table entries: 524288 (order: 9, 2097152 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 078bfbff e1d3fbff  
CPU: Common caps: 078bfbff e1d3fbff  
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 078bfbff e1d3fbff  
CPU: Common caps: 078bfbff e1d3fbff  
CPU0: AMD Opteron(tm) Processor 242 stepping 08
per-CPU timeslice cutoff: 2926.30 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 0004
ESR value after enabling vector: 
Booting processor 1/1 eip 3000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 
ESR value after enabling vector: 
Calibrating delay loop... 3185.04 BogoMIPS
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 078bfbff e1d3fbff  
CPU: Common caps: 078bfbff e1d3fbff  
CPU1: AMD Opteron(tm) Processor 242 stepping 08
Total of 2 

Re: 2.6.11-rc2-mm1

[Jörn Engel]

On Wed, 26 January 2005 00:17:34 +0300, Evgeniy Polyakov wrote:
> 
> That will catch only simple cases - for the whole picture you need
> to run graph generator from all allowed code pathes, but that
> will require knowledge of the tested system, so it will not and 
> actually can not be absolutely generic.

Oh, we both agree on that, although we used different words.  The
design actually is as simple as outlined, the messy part is getting
the complete call graph of the kernel in the first place.

I have a good deal of that part done, but the code is ugly and there
are legal issues... but it shows that it's quite possible to do.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra
-
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: sata_vsc, sata_core problem.... Please help me. (another clue)

[David Sims]

> On Mon, Jan 24, 2005 at 02:03:38PM -0600, David Sims wrote:
> > Hi,
> > 
> >   With kernel 2.6.10 on Intel (Dell Powervault 745N) When I insert the
> > sata_vsc module via 'modprobe sata_vsc' from the command line, the module
> > immediately recognizes the controller card and when it then enumerates the
> > attached disks, I am getting errors logged in syslog for each disk as
> > follows:
> > 
> > Jan 24 13:55:37 linux kernel: irq 3: nobody cared!
> > Jan 24 13:55:37 linux kernel:  [] __report_bad_irq+0x22/0x90
> > Jan 24 13:55:37 linux kernel:  [] note_interrupt+0x58/0x90
> > Jan 24 13:55:37 linux kernel:  [] __do_IRQ+0xd8/0xe0
> > Jan 24 13:55:37 linux kernel:  [] do_IRQ+0x1a/0x30
> > Jan 24 13:55:37 linux kernel:  [] common_interrupt+0x1a/0x20
> > Jan 24 13:55:37 linux kernel:  [] __do_softirq+0x30/0x90
> > Jan 24 13:55:37 linux kernel:  [] do_softirq+0x35/0x40
> > Jan 24 13:55:37 linux kernel:  [] do_IRQ+0x1f/0x30
> > Jan 24 13:55:37 linux kernel:  [] common_interrupt+0x1a/0x20
> > Jan 24 13:55:37 linux kernel:  [] default_idle+0x0/0x40
> > Jan 24 13:55:37 linux kernel:  [] default_idle+0x24/0x40
> > Jan 24 13:55:37 linux kernel:  [] cpu_idle+0x2e/0x40
> > Jan 24 13:55:37 linux kernel:  [] start_kernel+0x15b/0x190
> > Jan 24 13:55:37 linux kernel: handlers:
> > Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
> > Jan 24 13:55:37 linux kernel: [] (ide_intr+0x0/0x120)
> > Jan 24 13:55:37 linux kernel: [] (vsc_sata_interrupt+0x0/0xa0
> > [sata_vsc])
> > Jan 24 13:55:37 linux kernel: Disabling IRQ #3
> > 
> > 
> >   It seems to me that this driver is initializing itself and enabling
> > interrupts before it is fully loaded and ready to deal with them 
> > 
> >   If I insert the module during the boot up process, the machine just
> > hangs trying to read/identify the first disk... 
> > 
> >   Is there a way to disable or ignore these interrupts until the driver is
> > fully loaded, the disks are identified and all of the necessary
> > housekeeping is finished and the driver is finished loading?? 
> > 
> > Once the sata_vsc module finishes identifying the attached drives and
> > the 'modprobe sata_vsc' returns to the command prompt the errors stop
> > coming and it seems to work just fine You can fdisk and format the
> > disks and all is well... If I could just get it load at boot time I
> > would be happy
> >
> > Any advice would be welcome at this point. ;)
> >
> > TIA,
> >
> > Dave Sims
> 
> 
> Sorry, but I really don't have any clues at this point.  The driver is
> really more a set of subroutines, and most of this stuff is done by the
> libata and scsi i/f.
> 
> jeremy
> 

Hi again,

  This may sound like a dumb idea, but I decided to remove all the disks
from the SATA controller and fiddle with the module a
bit... So... Interestingly enough, the module loads without a peep both at
the command line AND when autoloading from rc.modules AND when builtin to
a monolithic kernel!! So... The interrupt problem is coming when the
controller tries to enumerate its disks... I have verified this by
unloading the module, installing one disk, and then reinserting the
module... I get 200,000 additional interrupts on IRQ3 in /proc/interrupts
and the normal error message shown above logged to syslog for the one
disk... 

  What do you think about that??

Dave


-
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: swap is never used on ultrasparc64/32 - 2.6.11-rc2 (STILL NOT SOLVED)

[gj]

On Wed, 26 Jan 2005 at 01:04:10, Renà Rebe wrote: 
 
> Hi, 
>  
> On 25. Jan 2005, at 18:40 Uhr, Grzegorz Piotr Jaskiewicz wrote: 
>  
> [...] 
>  
> I can confirm this. What is your last kernel that worked? I have no  
> data at hand - but I'm sure in either 2.6.8 or 2.6.10 swapping did  
> work. 
I've tried both 2.6.10 and 2.6.11-rc2. None of these works. I'll try earlier 
versions tommorow. Having very fast amd64 cross compilation computer helps in 
that a lot ;) 
 
--  
Grzegorz Jaskiewicz 
K4 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 7/12] random pt4: Update cryptolib to use SHA fro lib

[Matt Mackall]

On Tue, Jan 25, 2005 at 08:33:11PM -0500, Lee Revell wrote:
> On Fri, 2005-01-21 at 15:41 -0600, Matt Mackall wrote:
> >   * Copyright (c) Alan Smithee.
> >   * Copyright (c) Andrew McDonald <[EMAIL PROTECTED]>
> 
> Alan Smithee?

Aka anonymous contributor.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/

Fw: How to submit device ID into hid blacklist.

[dsuljic]

Hi,
I work for 3M Touch Systems (former MicroTouch) as software engineer and
our main product is touchscreen as input device.
Recently, we have released hid compliant devices (they work perfectly under
Windows OS), but Linux hid driver does not support us correctly. In kernel
2.4 hid driver recognizes our devices and tries to interpret events in best
manner, but since we are absolute pointing device it was a bit tricky with
hid mouse on same system. I kernel 2.6 hid core driver grubs our devices
but does not recognize us as hid device. So we decided, for now, to disable
hid driver of recognizing our hid devices.
My question is how can we submit changes to kernel tree.

Here is example of patch for kernel 2.6.10 hid-core.c:

--- drivers/usb/input/hid-core.c2004-12-24 16:34:58.0 -0500
+++ drivers/usb/input/hid-core.c2005-01-13 17:19:26.477523912 -0500
@@ -1469,6 +1469,12 @@
 #define USB_VENDOR_ID_DELORME0x1163
 #define USB_DEVICE_ID_DELORME_EARTHMATE 0x0100

+#define USB_VENDOR_ID_MICROTOUCH   0x0596
+#define USB_DEVICE_ID_MICROTOUCH_SC_4_8  0x0100
+#define USB_DEVICE_ID_MICROTOUCH_SC_50x0102
+#define USB_DEVICE_ID_MICROTOUCH_NFI50x0200
+#define USB_DEVICE_ID_MICROTOUCH_DST 0x0300
+
 static struct hid_blacklist {
  __u16 idVendor;
  __u16 idProduct;
@@ -1559,6 +1565,10 @@

  { USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE,
HID_QUIRK_IGNORE },

+ { USB_VENDOR_ID_MICROTOUCH, USB_DEVICE_ID_MICROTOUCH_SC_4_8,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_MICROTOUCH, USB_DEVICE_ID_MICROTOUCH_SC_5,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_MICROTOUCH, USB_DEVICE_ID_MICROTOUCH_NFI5,
HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_MICROTOUCH, USB_DEVICE_ID_MICROTOUCH_DST,
HID_QUIRK_IGNORE },
  { 0, 0 }
 };

Best regards,

Damir Suljic
3M Touch Systems
3M Optical Systems Division
300 Griffin Brook Park Drive
Methuen, MA 01844
978-659-9386
[EMAIL PROTECTED]
www.3Mtouch.com
www.touchshowcase.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: possible CPU bug and request for Intel contacts

[Seth, Rohit]

Kirill Korotaev  wrote on Tuesday, January 25, 2005
6:12 AM:

> Hello Rohit,
> 
>>> BTW, can you explain why making pages non-global is the cure? Is it
>>> safe workaround for this bug?

>> There is a boundary condition that can have non-global pages
>> containing the CR3 load to also hit this issue on affected PIII. 
>> Though for this to happen, mov to cr3 has to be the very last
>> instruction on a page. And the page following that page (containing
>> CR3 load) has to have different mapping between user and kernel
>> spaces. 

> but in our case "mov %edx, %cr3" is not the last instruction on a
> page. 
> It is in the middle of it.

So, in this scenario (where trampoline code is mapped by non global
page), we will not hit this issue.

> Well, another remark is that after cr3 load there are only few
> instructions before the "call system_call_table(%edx)" which
> references 
> the page with different user and kernel mappings.
> 
> also, this bug can be cured via inserting about 20 simple operations
> between cr3 load and call to the page with overlapping mappings.
> 

This is not a recommended solution.

> I'm just trying to understand is it the bug referenced in E80 or not
> and 
> is it safe to use non-global mappings as a cure.

Our analysis has shown that this is E80 issue.  In this 4G-4G kernel
context, we are safe to use non-global mapping as a workaround for this
issue. (Or we can use any of the other recommendations given in the spec
update except rdtsc with global pages).

We have also seen that inserting rdtsc instruction is not a workaround.
We will update the spec update with this information.

On a little different note, while running the 4G-4G kernel on our
machine, we saw occasional hangs.  Those are root caused to the fact
that this kernel was first chaging the stack pointer from virtual stack
to kernel and then changing the CR3 to that of kernel.  Any interrupt
between these two instructions will result in those hangs as the
interruption handler will execute with user's CR3(as the kernel thinks
that it is already in kernel because of the value of esp).  Swapping the
order, first loading the CR3 with kernel and then switching the stack to
kernel fixes this issue.  Venki will generate that patch and send to
lkml.

Thanks, rohit

-
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 7/12] random pt4: Update cryptolib to use SHA fro lib

[Lee Revell]

On Fri, 2005-01-21 at 15:41 -0600, Matt Mackall wrote:
>   * Copyright (c) Alan Smithee.
>   * Copyright (c) Andrew McDonald <[EMAIL PROTECTED]>

Alan Smithee?

-
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][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

Greg, Philip,
Marvell makes a line of host bridge for PPC and MIPS systems.  On those 
bridges is an i2c controller.  This patch adds the driver for that i2c 
controller.

Please let me know if you see any problems with this patch.
Also, if you're not the correct person(s), please point me to who is.
Thanks,
Mark
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-01-25 18:15:24 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-01-25 18:15:24 -07:00
@@ -476,4 +476,14 @@
  This driver can also be built as a module.  If so, the module
  will be called i2c-pca-isa.
 
+config I2C_MV64XXX
+   tristate "Marvell mv64xxx I2C Controller"
+   depends on I2C && MV64X60
+   help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mv64xxx.
+
 endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile   2005-01-25 18:15:24 -07:00
+++ b/drivers/i2c/busses/Makefile   2005-01-25 18:15:24 -07:00
@@ -20,6 +20,7 @@
 obj-$(CONFIG_I2C_IXP4XX)   += i2c-ixp4xx.o
 obj-$(CONFIG_I2C_KEYWEST)  += i2c-keywest.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_NFORCE2)  += i2c-nforce2.o
 obj-$(CONFIG_I2C_PARPORT)  += i2c-parport.o
 obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c  2005-01-25 18:15:24 -07:00
@@ -0,0 +1,550 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ * 
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc.  This file is licensed under
+ * the terms of the GNU General Public License version 2.  This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "i2c-mv64xxx.h"
+
+/*
+ *
+ *
+ * Finite State Machine & Interrupt Routines
+ *
+ *
+ */
+static inline void
+mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
+{
+   pr_debug("mv64xxx_i2c_fsm: ENTER--state: %d, status: 0x%x\n",
+   drv_data->state, status);
+
+   /*
+* If state is idle, then this is likely the remnants of an old
+* operation that driver has given up on or the user has killed.
+* If so, issue the stop condition and go to idle.
+*/
+   if (drv_data->state == MV64XXX_I2C_STATE_IDLE) {
+   drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+   drv_data->state = MV64XXX_I2C_STATE_IDLE;
+   pr_debug("mv64xxx_i2c_fsm: EXIT--Entered when in IDLE state\n");
+   return;
+   }
+
+   if (drv_data->state == MV64XXX_I2C_STATE_ABORTING) {
+   drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
+   drv_data->state = MV64XXX_I2C_STATE_IDLE;
+   pr_debug("mv64xxx_i2c_fsm: EXIT--Aborting\n");
+   return;
+   }
+
+   /* The status from the ctlr [mostly] tells us what to do next */
+   switch (status) {
+   /* Start condition interrupt */
+   case MV64XXX_I2C_STATUS_MAST_START: /* 0x08 */
+   case MV64XXX_I2C_STATUS_MAST_REPEAT_START: /* 0x10 */
+   drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_1;
+   drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK;
+   break;
+
+   /* Performing a write */
+   case MV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK: /* 0x18 */
+   if (drv_data->msg->flags & I2C_M_TEN) {
+   drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_2;
+   drv_data->state =
+   MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
+   break;
+   }
+   /* FALLTHRU */
+   case MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK: /* 0xd0 */
+   case MV64XXX_I2C_STATUS_MAST_WR_ACK: /* 0x28 */
+   if (drv_data->bytes_left > 0) {
+   drv_data->action = MV64XXX_I2C_ACTION_SEND_DATA;
+   drv_data->state =
+   MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK;
+   

Re: [PATCH 2/4] page_cache_readahead: remove duplicated code

[Steven Pratt]

Ram wrote:
On Tue, 2005-01-25 at 03:59, Oleg Nesterov wrote:
 

Cases "no ahead window" and "crossed into ahead window"
can be unified.
   


No. There is a reason why we had some duplication. With your patch,
we will end up reading-on-demand instead of reading ahead.
When we notice a sequential reads have resumed, we first read in the
data that is requested. 
However if the read request is for more pages than what are being held
in the current window, we make the ahead window as the current window
and read in more pages in the ahead window. Doing that gives the
opportunity of always having pages in the ahead window when the next
sequential read request comes in.  If we apply this patch, we will
always have to read the pages that are being requested instead of
satisfying them from the ahead window.
 

Ah, you are right! 

Ok, if this does not make it clear, here is another way of proving that
your patch does not exactly behave the way it did earlier.
With your patch you will have only one call to
block_page_cache_readahead(), when earlier there could be cases where
block_page_cache_readahead() could be called twice.
Am I am making sense?
Completely, this patch should not be applied.  Good catch.
Steve
RP
 

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

[PATCH] fix broken cross compiles

[James Bottomley]

This patch:

kbuild: Use -isystem `gcc -print-file-name=include`

broke our parisc crosscompile (and presumably everyone else's).

The reason is that you have a := in the NOSTDINC_FLAGS rule, which is
evaluated in situ (i.e. before we've had a chance to set CROSSCOMPILE on
CC) so the gcc include path is actually the native one not the
crosscompiler one.  On parisc this causes us to be unable to handle
_builtin_va functions, but I bet there are a heap of other problems.

The fix is below

James

= Makefile 1.561 vs edited =
--- 1.561/Makefile  2005-01-21 19:45:34 -06:00
+++ edited/Makefile 2005-01-25 17:13:51 -06:00
@@ -331,7 +331,7 @@
 PERL   = perl
 CHECK  = sparse
 
-NOSTDINC_FLAGS := -nostdinc -isystem $(shell $(CC) -print-file-name=include)
+NOSTDINC_FLAGS  = -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__
 CHECKFLAGS += $(NOSTDINC_FLAGS)
 MODFLAGS   = -DMODULE


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

Re: 2.6.11-rc2: Badness in local_bh_enable at kernel/softirq.c:140

[Herbert Xu]

Bart De Schuymer <[EMAIL PROTECTED]> wrote:
> 
> Thanks for posting this. I was just about to go on a wild goose chase.
> Any idea what patch fixed it?

It's this one:

http://article.gmane.org/gmane.linux.kernel/273477
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Configure mangles hex values

[Keith Owens]

On Tue, 25 Jan 2005 09:25:57 -0800, 
Nick Pollitt <[EMAIL PROTECTED]> wrote:
>Hello.  I'm thinking that the 0x was stripped for purely cosmetic reasons 
>rather than anything functional.  I had originally thought that the readln 
>function might need the formatting, but taking a closer look at it now I 
>don't see any need.

Agreed.  Apply the patch.

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

Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

[john stultz]

On Tue, 2005-01-25 at 09:17 +0100, Andi Kleen wrote:
> On Mon, Jan 24, 2005 at 02:51:29PM -0800, john stultz wrote:
> > All,
> > Here is a new release of my time of day proposal, which include ppc64
> > support as well as suspend/resume and cpufreq hooks. For basic summary
> > of my ideas, you can follow this link: http://lwn.net/Articles/100665/
> 
> [...]
> How do vsyscalls (running gettimeofday in user space) fit into your 
> architecture? I don't see any provision for this.

Yea, I had some earlier ideas for it, although they were misconceived.
My plan at the moment is to do it similarly to how x86-64 and my i386
patch did it, but still have it on an arch-per-arch basis.

> Also on x86-64 we plan to keep the cycle time base per CPU, that 
> will likely require some more changes to your architecture too.

I like to hear more details, if you can discuss it. Its interesting,
because I don't quite see how you'd be able to do this.

thanks
-john

-
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/7] posix-timers: CPU clock support for POSIX timers

[Chris Wedgwood]

On Tue, Jan 25, 2005 at 03:39:12PM -0800, George Anzinger wrote:

> I would like to get a read on the following defines...
> #define mmclock mmtimer.clock
> #define mmnode  mmtimer.node
> #define mmincr  mmtimer.incr
> #define mmexpires mmtimer.expires

Ick, we already abuse the preprocessor too much, I really don't like
that.  Yes, it saves a few keystrokes but makes things hard to find
and/or more vague when using cscope/grep, etc.
-
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-rc2-V0.7.36-00

[Lee Revell]

On Mon, 2005-01-24 at 09:02 +0100, Ingo Molnar wrote:
> indeed - !PREEMPT_RT compilation broke. I've uploaded -03 with the fix
> (and other fixes).

-03 still does not compile with CONFIG_PREEMPT_DESKTOP:

[EMAIL PROTECTED]:~/kernel-source/linux-2.6.11-rc2$ make
  CHK include/linux/version.h
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
  CHK include/linux/compile.h
  CHK usr/initramfs_list
  CC  net/core/rtnetlink.o
net/core/rtnetlink.c: In function `rtnl_lock_interruptible':
net/core/rtnetlink.c:63: warning: implicit declaration of function 
`down_write_interruptible'
  LD  net/core/built-in.o
  LD  net/built-in.o
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
net/built-in.o(.text+0x10f99): In function `rtnl_lock_interruptible':
net/core/rtnetlink.c:63: undefined reference to `down_write_interruptible'
make: *** [.tmp_vmlinux1] Error 1

Lee

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

[Announce] megaraid_mbox 2.20.4.3 patch

[Ju, Seokmann]

Hello,

Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5.
The patch includes following changes/fixes
- sysfs support for drive addition/removal
- Tape drive timeout issue
- Made some code static

I am attaching and inlining the patch.

Thank you.

Seokmann
LSI Logic

---

diff -Naur linux_bk/Documentation/scsi/ChangeLog.megaraid
linux_bk.new/Documentation/scsi/ChangeLog.megaraid
--- linux_bk/Documentation/scsi/ChangeLog.megaraid    2005-01-25
18:12:46.0 -0500
+++ linux_bk.new/Documentation/scsi/ChangeLog.megaraid  2005-01-25
18:21:48.525354048 -0500
@@ -1,3 +1,77 @@
+Release Date : Fri Jan 21 00:01:03 EST 2005 - Atul Mukker
<[EMAIL PROTECTED]>
+Current Version  : 2.20.4.3 (scsi module), 2.20.2.5 (cmm module)
+Older Version    : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module)
+
+i.   Remove driver ioctl for logical drive to scsi address translation and
+ replace with the sysfs attribute. To remove drives and change
+ capacity, application shall now use the device attribute to get the
+ logical drive number for a scsi device. For adding newly created
+ logical drives, class device attribute would be required to uniquely
+ identify each controller.
+   - Atul Mukker <[EMAIL PROTECTED]>
+
+ "James, I've been thinking about this a little more, and you may be on
+ to something here. Let each driver add files as such:"
+
+   - Matt Domsch <[EMAIL PROTECTED]>, 12.15.2004
+   linux-scsi mailing list
+
+
+ "Then, if you simply publish your LD number as an extra parameter of
+ the device, you can look through /sys to find it."
+
+   - James Bottomley <[EMAIL PROTECTED]>, 01.03.2005
+   linux-scsi mailing list
+
+
+ "I don't see why not ... it's your driver, you can publish whatever
+ extra information you need as scsi_device attributes; that was one of
+ the designs of the extensible attribute system."
+
+   - James Bottomley <[EMAIL PROTECTED]>, 01.06.2005
+   linux-scsi mailing list
+
+ii.  Add AMI megaraid support - Brian King <[EMAIL PROTECTED]>
+   PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
+   PCI_VENDOR_ID_AMI, PCI_SUBSYS_ID_PERC3_DC,
+
+iii. Make some code static
+   - Adrian Bunk <[EMAIL PROTECTED]>, 11.15.2004
+   linux-scsi mailing list
+
+iv.  Added NEC ROMB support - NEC MegaRAID PCI Express ROMB controller
+   PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_MEGARAID_NEC_ROMB_2E,
+   PCI_SUBSYS_ID_NEC, PCI_SUBSYS_ID_MEGARAID_NEC_ROMB_2E,
+
+v.   Fixed Tape drive issue : For any Direct CDB command to physical device
+ including tape, timeout value set by driver was 10 minutes. With this
+ value, most of command will return within timeout. However, for those
+ command like ERASE or FORMAT, it takes more than an hour depends on
+ capacity of the device and the command could be terminated before it
+ completes.
+ To address this issue, the 'timeout' field in the DCDB command will
+ have NO TIMEOUT (i.e., 4) value as its timeout on DCDB command.
+
+
+Release Date : Thu Dec  9 19:10:23 EST 2004
+ - Sreenivas Bagalkote <[EMAIL PROTECTED]>
+
+Current Version  : 2.20.4.2 (scsi module), 2.20.2.4 (cmm module)
+Older Version    : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module)
+
+i.   Introduced driver ioctl that returns scsi address for a given ld.
+
+ "Why can't the existing sysfs interfaces be used to do this?"
+   - Brian King ([EMAIL PROTECTED])
+
+ "I've looked into solving this another way, but I cannot see how
+ to get this driver-private mapping of logical drive number-> HCTL
+ without putting code something like this into the driver."
+
+ "...and by providing a mapping a function to userspace, the driver
+ is free to change its mapping algorithm in the future if necessary .."
+   - Matt Domsch ([EMAIL PROTECTED])
+
 Release Date : Thu Dec  9 19:02:14 EST 2004 - Sreenivas Bagalkote
<[EMAIL PROTECTED]>
 
 Current Version  : 2.20.4.1 (scsi module), 2.20.2.3 (cmm module)
diff -Naur linux_bk/drivers/scsi/megaraid/Kconfig.megaraid
linux_bk.new/drivers/scsi/megaraid/Kconfig.megaraid
--- linux_bk/drivers/scsi/megaraid/Kconfig.megaraid   2005-01-25
18:13:37.0 -0500
+++ linux_bk.new/drivers/scsi/megaraid/Kconfig.megaraid 2005-01-25
18:22:19.382663024 -0500
@@ -59,6 +59,7 @@
  INTEL RAID Controller SRCU51L 1000:1960:8086:0520
  FSC MegaRAID PCI Express ROMB 1000:0408:1734:1065
  ACER MegaRAID ROMB-2E 1000:0408:1025:004D
+ NEC MegaRAID PCI Express ROMB 1000:0408:1033:8287
 
  To compile this driver as a module, choose M here: the
  module will be called megaraid_mbox
diff -Naur linux_bk/drivers/scsi/megaraid/mega_common.h
linux_bk.new/drivers/scsi/megaraid/mega_common.h
--- linux_bk/drivers/scsi/megaraid/mega_common.h  2005-01-25
18:13:37.0 -0500
+++ linux_bk.new/drivers/scsi/megaraid/mega_common.h  

Resubmittal [PATCH 1/2] Disallow appends to sysfs files

[Mitch Williams]

This patch returns an error code if the caller attempts to open a sysfs
file for appending.

Generated from 2.6.11-rc2.

Signed-off-by:  Mitch Williams <[EMAIL PROTECTED]>

diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c 
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs/sysfs/file.c  2004-12-24 13:33:50.0 -0800
+++ linux-2.6.11/fs/sysfs/file.c2005-01-25 14:59:33.0 -0800
@@ -275,6 +275,15 @@ static int check_perm(struct inode * ino
if (!ops)
goto Eaccess;

+/* Return error if the file is open for append.
+ * Sysfs can't support append because the kobject
+ * store methods don't take an offset into the buffer
+ * as an argument.  They end up thinking the appended
+ * data is the entire contents of the file.
+ */
+   if (file->f_flags & O_APPEND)
+   goto Einval;
+
/* File needs write support.
 * The inode's perms must say it's ok,
 * and we must have a store method.
-
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/7] posix-timers: CPU clock support for POSIX timers

[Roland McGrath]

> Your patch breaks the mmtimer driver because it used k_itimer values for
> its own purposes. Here is a fix by defining an additional structure
> in k_itimer (same approach for mmtimer as the cpu timers):

This seems reasonable enough to me.  Perhaps if there will be lots of timer
guts implementations, and more coming in modules or whatnot, then the union
should be replaced with a more generic private-data buffer, or at least
have a vanilla padding alternative in the union.  But I am certainly happy
with the simple path of just adding in the implementations as they come
like you've done for mmtimer.


Thanks,
Roland
-
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] update Dag Brattli's email address

[Chris Wedgwood]

On Tue, Jan 25, 2005 at 03:40:46PM +0100, Adrian Bunk wrote:

> This patch updates the email address of Dag Brattli in kernel 2.6 to
> his current address.

>  drivers/net/irda/actisys-sir.c|4 ++--
[ ... 
>  CREDITS   |6 +-
>  96 files changed, 233 insertions(+), 237 deletions(-)

This patch is huge.

Do we really need email addresses in all these files?  How about we
remove them and put it in ONE place instead so if it needs to be
updated again we don't need to touch ~96 files?

Surely this makes sense in general too?


-
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 space out of memory approach

[Andrea Arcangeli]

On Tue, Jan 25, 2005 at 08:11:19PM -0400, Mauricio Lin wrote:
> Sometimes the first application to be killed is XFree. AFAIK the

This makes more sense now. You need somebody trapping sigterm in order
to lockup and X sure traps it to recover the text console.

Can you replace this:

if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}

with this?

force_sig(SIGKILL, p);

in mm/oom_kill.c.

This should fix it. Problem is that SIGTERM is unsafe even if the app is
not malicious, there's not enough ram to pagein the userland sighander,
so the system lockups.

We need a sort of timeout where we fallback into SIGKILL if SIGTERM
didn't help.

Anyway this is not a new bug, I didn't touch a single bit in that code.
I'd really like to see current fixes merged, then we can take care of
root app getting killed reliably. In all my test I always run the
malicious app as non-root, and anyway I never trap sigterm (X is tiny in
my setup, so it never gets killed). Probably the GUI stuff you opened
has increased significantly X size for X to be killed.
-
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: thoughts on kernel security issues

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Bill Davidsen wrote:
> On Tue, 25 Jan 2005, John Richard Moser wrote:
> 
> 
> 
>>Thus, by having fewer exploits available, fewer successful attacks
>>should happen due to the laws of probability.  So the goal becomes to
>>fix as many bugs as possible, but also to mitigate the ones we don't
>>know about.  To truly mitigate any security flaw, we must make a
>>non-circumventable protection.
> 
> 
> To the extent that this means "if you see a bug, fix the bug, even if it's
> unrelated" I agree completely.
> 

That's the old, old, OLD method.  :)  It's a fundamental principle of
good programming, a good one that some people (*cough*Microsoft*Cough*)
have forgotten, and we see the results and know not to forget it ourselves.

But I also like to go beyond that, to the extent that if you toss a
wrench in it, it'll sieze up, but won't break.  Some of this is
userspace, and some is kernelspace.  It's possible to fix userspace
problems like code injection and tempfile races with kernel level
policies on memory protections and filesystem intrinsics
(symlink/hardlink rules).

I believe that these and similar concepts should be explored, so that we
can truly progress rather than simply continue in the archaic manner
that we use today.  Eventually we will evolve from "look for security
vulns and fix them before they're exploited" to "fix unhandled security
vulns first, and treat handled vulns as normal bugs."  That is, we'll
still fix the bugs; but we'll have a much smaller range of bugs that are
actually exploitable, and thus a better, smaller, more refined set of
high-priority focus issues.

We already do this with everything else.  The kernel developers, both
LKML and external projects, have and are still exploring new schedulers
for disk, IO, and networking; new memory managment and threading models;
and new security concepts.  We have everything from genetics algorithms
to binary signing on the outside, as well as a O(1) CPU scheduler and
security hook framework in vanilla.  I want things to just continue moving.

It's interesting to me mainly that something like 80% of the USNs Ubuntu
puts out contain exploits that could only manage to be used as DoS
attacks if the right systems were put in place, only counting the ones I
actually know and understand myself.  Not all of those protections are
kernel-based, but the kernel based ones 'should' touch on each exploit
in some way.  I believe these are suitable for widespread deployment, so
of course my idea of progress includes widespread deployment of these :)

It's not entirely relavent to argue this here, but it gives me something
to do while I'm extremely bored (hell I've even done an LSM clone that's
simpler and implements full stacking just to occupy myself).  Hopefully
the Ubuntu developers deploy and run this stuff, so after being around
4-6 years, the merits of some often overlooked systems will finally be
widely demonstrated and assessable.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9ucWhDd4aOud5P8RAt57AJwNGyBm9jn87da+JJCbnYXQp+KH4QCbBupJ
mEPqyDIE7ZZitAG1tTKo4qI=
=rCVA
-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/

[RFC][PATCH 3/5] remove-free_all_bootmem() #define

[Dave Hansen]

in arch/i386/mm/init.c, there's a #define for __free_all_bootmem():

#ifndef CONFIG_DISCONTIGMEM
#define __free_all_bootmem() free_all_bootmem()
#else
#define __free_all_bootmem() free_all_bootmem_node(NODE_DATA(0))
#endif /* !CONFIG_DISCONTIGMEM */

However, both of those functions end up eventuall calling the same
thing:

free_all_bootmem_core(NODE_DATA(0))

This might have once been a placeholder for a more complex bootmem
init call, but that never happened.  So, kill off the DISCONTIG
version, and just call free_all_bootmem() directly in both cases.

---

 memhotplug-dave/arch/i386/mm/init.c |8 +---
 1 files changed, 1 insertion(+), 7 deletions(-)

diff -puN arch/i386/mm/init.c~A1.3-remove-free_all_bootmem-define 
arch/i386/mm/init.c
--- memhotplug/arch/i386/mm/init.c~A1.3-remove-free_all_bootmem-define  
2005-01-25 13:59:50.0 -0800
+++ memhotplug-dave/arch/i386/mm/init.c 2005-01-25 14:00:14.0 -0800
@@ -579,12 +579,6 @@ static void __init set_max_mapnr_init(vo
 #endif
 }
 
-#ifndef CONFIG_DISCONTIGMEM
-#define __free_all_bootmem() free_all_bootmem()
-#else
-#define __free_all_bootmem() free_all_bootmem_node(NODE_DATA(0))
-#endif /* !CONFIG_DISCONTIGMEM */
-
 static struct kcore_list kcore_mem, kcore_vmalloc; 
 
 void __init mem_init(void)
@@ -620,7 +614,7 @@ void __init mem_init(void)
 #endif
 
/* this will put all low memory onto the freelists */
-   totalram_pages += __free_all_bootmem();
+   totalram_pages += free_all_bootmem();
 
reservedpages = 0;
for (tmp = 0; tmp < max_low_pfn; tmp++)
_
-
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][SERIAL] mpsc updates

[Mark A. Greer]

Hi again, Andrew.
This patch:
- replaces several macros with the actual code
- change the type of pointer variables from u32 to void *
- removes unecessary casts
- puts the contents of mpsc_defs.h into mpsc.h and removes the mpsc_defs.h
- reflects the new names of some structs
- cleans up some whitespace
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/serial/mpsc.c b/drivers/serial/mpsc.c
--- a/drivers/serial/mpsc.c 2005-01-25 17:28:43 -07:00
+++ b/drivers/serial/mpsc.c 2005-01-25 17:28:43 -07:00
@@ -36,16 +36,14 @@
  *
  * 1) Some chips have an erratum where several regs cannot be
  * read.  To work around that, we keep a local copy of those regs in
- * 'mpsc_port_info' and use the *_M or *_S macros when accessing those regs.
+ * 'mpsc_port_info'.
  *
  * 2) Some chips have an erratum where the ctlr will hang when the SDMA ctlr
- * accesses system mem in a cache coherent region.  This *should* be a
- * show-stopper when coherency is turned on but it seems to work okay as
- * long as there are no snoop hits.  Therefore, the ring buffer entries and
- * the buffers themselves are allocated via 'dma_alloc_noncoherent()' and
- * 'dma_cache_sync()' is used.  Also, since most PPC platforms are coherent
- * which makes 'dma_cache_sync()' a no-op, explicit cache management macros
- * have been added ensuring there are no snoop hits when coherency is on.
+ * accesses system mem with coherency enabled.  For that reason, the driver
+ * assumes that coherency for that ctlr has been disabled.  This means
+ * that when in a cache coherent system, the driver has to manually manage
+ * the data cache on the areas that it touches because the dma_* macro are
+ * basically no-ops.
  *
  * 3) There is an erratum (on PPC) where you can't use the instruction to do
  * a DMA_TO_DEVICE/cache clean so DMA_BIDIRECTIONAL/flushes are used in places
@@ -54,7 +52,6 @@
  * 4) AFAICT, hardware flow control isn't supported by the controller --MAG.
  */
 
-#include 
 #include "mpsc.h"
 
 /*
@@ -81,25 +78,48 @@
 static void
 mpsc_brg_init(struct mpsc_port_info *pi, u32 clk_src)
 {
+   u32 v;
+
+   v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+   v = (v & ~(0xf << 18)) | ((clk_src & 0xf) << 18);
+
if (pi->brg_can_tune)
-   MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 25, 0);
+   v &= ~(1 << 25);
+
+   if (pi->mirror_regs)
+   pi->BRG_BCR_m = v;
+   writel(v, pi->brg_base + BRG_BCR);
 
-   MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 4, 18, clk_src);
-   MPSC_MOD_FIELD(pi, brg, BRG_BTR, 16, 0, 0);
+   writel(readl(pi->brg_base + BRG_BTR) & 0x,
+   pi->brg_base + BRG_BTR);
return;
 }
 
 static void
 mpsc_brg_enable(struct mpsc_port_info *pi)
 {
-   MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 16, 1);
+   u32 v;
+
+   v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+   v |= (1 << 16);
+
+   if (pi->mirror_regs)
+   pi->BRG_BCR_m = v;
+   writel(v, pi->brg_base + BRG_BCR);
return;
 }
 
 static void
 mpsc_brg_disable(struct mpsc_port_info *pi)
 {
-   MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 1, 16, 0);
+   u32 v;
+
+   v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+   v &= ~(1 << 16);
+
+   if (pi->mirror_regs)
+   pi->BRG_BCR_m = v;
+   writel(v, pi->brg_base + BRG_BCR);
return;
 }
 
@@ -115,10 +135,16 @@
 * that accounts for the way the mpsc is set up is:
 * CDV = (clk / (baud*2*16)) - 1 ==> CDV = (clk / (baud << 5)) - 1.
 */
-   u32 cdv = (pi->port.uartclk / (baud << 5)) - 1;
+   u32 cdv = (pi->port.uartclk / (baud << 5)) - 1;
+   u32 v;
 
mpsc_brg_disable(pi);
-   MPSC_MOD_FIELD_M(pi, brg, BRG_BCR, 16, 0, cdv);
+   v = (pi->mirror_regs) ? pi->BRG_BCR_m : readl(pi->brg_base + BRG_BCR);
+   v = (v & 0x) | (cdv & 0x);
+
+   if (pi->mirror_regs)
+   pi->BRG_BCR_m = v;
+   writel(v, pi->brg_base + BRG_BCR);
mpsc_brg_enable(pi);
 
return;
@@ -135,7 +161,7 @@
 static void
 mpsc_sdma_burstsize(struct mpsc_port_info *pi, u32 burst_size)
 {
-   u32 v;
+   u32 v;
 
pr_debug("mpsc_sdma_burstsize[%d]: burst_size: %d\n",
pi->port.line, burst_size);
@@ -151,7 +177,8 @@
else
v = 0x3;/* 8 64-bit words */
 
-   MPSC_MOD_FIELD(pi, sdma, SDMA_SDC, 2, 12, v);
+   writel((readl(pi->sdma_base + SDMA_SDC) & (0x3 << 12)) | (v << 12),
+   pi->sdma_base + SDMA_SDC);
return;
 }
 
@@ -161,7 +188,8 @@
pr_debug("mpsc_sdma_init[%d]: burst_size: %d\n", pi->port.line,
burst_size);
 
-   MPSC_MOD_FIELD(pi, sdma, SDMA_SDC, 10, 0, 0x03f);
+   writel((readl(pi->sdma_base + SDMA_SDC) & 0x3ff) | 0x03f,
+   pi->sdma_base + SDMA_SDC);
mpsc_sdma_burstsize(pi, 

Re: patch to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[Zephaniah E. Hull]

On Wed, Jan 26, 2005 at 12:02:51AM +, J.A. Magallon wrote:
> 
> On 2005.01.25, Zephaniah E. Hull wrote:
> > On Tue, Jan 25, 2005 at 12:56:25PM +, J.A. Magallon wrote:
> > 
> > > You can use the latest drivers (6629) with this patches:
> > > 
> > > http://www.minion.de/files/1.0-6629/
> > > 
> > > They work fine up to -rc2.
> > > 
> > > If you want to use the driver with -mm, you have to kill the support
> > > for AGPGART in nvidia driver, add -DNOAGPGART to EXTRA_CFLAGS in the
> > > makefile. It will require a big change to use the multi-agp patches
> > > in -mm. But you are restricted to those AGPs supported by nvidia
> > > (ah, and don't load any agp related module...).
> > 
> > For values of big changes that equal the attached patch.
> > 
> > I'm using it on 2.6.10-mm3.  I sent it to Zander however since there is
> > no way to detect the new multi-agp support barring some sick hacks it
> > has not gone in.
> > 
> > It may conflict with the support for the 2.6.11-rc kernels, in which
> > case when I next upgrade I'll find out and write a new one.
> > > 
> > > Ah, just a ton of workarounds
> > 
> 
> Hay, that gave me the clues I was missing !!!
> With patch below, I get 6629 working on 2.6.10-rc2-mm1. Apply it on top of
> all the patches in the link above.
> 
> I know, it is ugly as hell (all those superfluos parameters in NV_AGPGART
> macros, unused drm_agp_p...), but perhaps someone  will rework all that
> macro mesh. For the moment, it works

A better fix would be to move drm_agp_p over into nv_linux_state_t, then
all we have to do is pass nvl and we get rid of some warnings.

When I move to the -rc-mm kernels I'll write up the larger patch,
though with the multi-agp support controlled by an ifdef that's disabled
by default for the sake of wider testing.

Leaving the patch below and CCing zander just so he knows about the
updated patch and such.
> 
> diff -ruN nv-6629-jam/src/nv/nv-linux.h nv-6629-jam-2/src/nv/nv-linux.h
> --- nv-6629-jam/src/nv/nv-linux.h 2005-01-24 23:16:46.0 +0100
> +++ nv-6629-jam-2/src/nv/nv-linux.h   2005-01-26 00:25:10.0 +0100
> @@ -930,6 +930,9 @@
>  
>  /* lock for linux-specific alloc queue */
>  struct semaphore at_lock;
> +
> + /* AGP bridge handle */
> + struct agp_bridge_data *agp_bridge;
>  } nv_linux_state_t;
>  
>  
> diff -ruN nv-6629-jam/src/nv/nv.c nv-6629-jam-2/src/nv/nv.c
> --- nv-6629-jam/src/nv/nv.c   2005-01-24 23:16:46.0 +0100
> +++ nv-6629-jam-2/src/nv/nv.c 2005-01-26 00:47:14.0 +0100
> @@ -3011,10 +3011,11 @@
>  return -1;
>  }
>  #elif defined(AGPGART)
> -int error;
> -if ((error = agp_backend_acquire()) != -EINVAL)
> + nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
> + nvl->agp_bridge = agp_backend_acquire(nvl->dev);
> +if (nvl->agp_bridge)
>  {
> -if (!error) agp_backend_release();
> +agp_backend_release(nvl->agp_bridge);
>  nv_printf(NV_DBG_WARNINGS,
>"NVRM: not using NVAGP, an AGPGART backend is 
> loaded!\n");
>  return -1;
> diff -ruN nv-6629-jam/src/nv/os-agp.c nv-6629-jam-2/src/nv/os-agp.c
> --- nv-6629-jam/src/nv/os-agp.c   2005-01-24 23:16:46.0 +0100
> +++ nv-6629-jam-2/src/nv/os-agp.c 2005-01-26 00:49:01.0 +0100
> @@ -60,23 +60,23 @@
>  #endif
>  
>  #if defined(KERNEL_2_6)
> -#define NV_AGPGART_BACKEND_ACQUIRE(o) agp_backend_acquire()
> -#define NV_AGPGART_BACKEND_ENABLE(o,mode) agp_enable(mode)
> -#define NV_AGPGART_BACKEND_RELEASE(o) agp_backend_release()
> -#define NV_AGPGART_COPY_INFO(o,p) agp_copy_info(p)
> -#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) 
> agp_allocate_memory(count,type)
> -#define NV_AGPGART_FREE_MEMORY(o,p) agp_free_memory(p)
> -#define NV_AGPGART_BIND_MEMORY(o,p,offset) agp_bind_memory(p,offset)
> -#define NV_AGPGART_UNBIND_MEMORY(o,p) agp_unbind_memory(p)
> +#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ nvl->agp_bridge = 
> agp_backend_acquire(nvl->dev); !nvl->agp_bridge; })
> +#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) 
> agp_enable(nvl->agp_bridge,mode)
> +#define NV_AGPGART_BACKEND_RELEASE(nvl,o) 
> agp_backend_release(nvl->agp_bridge)
> +#define NV_AGPGART_COPY_INFO(nvl,o,p) agp_copy_info(nvl->agp_bridge,p)
> +#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type) 
> agp_allocate_memory(nvl->agp_bridge,count,type)
> +#define NV_AGPGART_FREE_MEMORY(nvl,o,p) agp_free_memory(p)
> +#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) agp_bind_memory(p,offset)
> +#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) agp_unbind_memory(p)
>  #elif defined(KERNEL_2_4)
> -#define NV_AGPGART_BACKEND_ACQUIRE(o) ({ (o)->acquire(); 0; })
> -#define NV_AGPGART_BACKEND_ENABLE(o,mode) (o)->enable(mode)
> -#define NV_AGPGART_BACKEND_RELEASE(o) ((o)->release())
> -#define NV_AGPGART_COPY_INFO(o,p) ({ (o)->copy_info(p); 0; })
> -#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) 
> 

[RFC][PATCH 4/5] memset the i386 numa pgdats in arch code

[Dave Hansen]

The next patch in this series will remove the  arch-independent
clearing of the pgdat's, which only i386 depends on.  This removes
the i386 dependency on that behavior.

The new i386 function, remapped_pgdat_init() takes care of
initializing the pgdats which are finally mapped after
paging_init() is done.  The zone_sizes_init() call has to occur
after the pgdat clearing

zone_sizes_init() is currently called from the end of paging_init(),
because that's the first place where the pgdats could have been
zeroed.  However, zone_sizes_init() really doesn't have anything
to do with paging, and probably shouldn't be in paging_init().

Moving this call into setup_memory() allows the declaration of
zone_sizes_init() to change files as well, which means a net
removal of one #ifdef.  It also provides a handy place to put
the new function, far away from the paging code that it really
has nothing to do with.


---

 memhotplug-dave/arch/i386/kernel/setup.c |   42 +++
 memhotplug-dave/arch/i386/mm/discontig.c |4 --
 memhotplug-dave/arch/i386/mm/init.c  |   26 ---
 3 files changed, 43 insertions(+), 29 deletions(-)

diff -puN arch/i386/kernel/setup.c~A2.1-re-memset-i386-pgdats 
arch/i386/kernel/setup.c
--- memhotplug/arch/i386/kernel/setup.c~A2.1-re-memset-i386-pgdats  
2005-01-25 13:04:30.0 -0800
+++ memhotplug-dave/arch/i386/kernel/setup.c2005-01-25 13:41:12.0 
-0800
@@ -1100,8 +1100,30 @@ static unsigned long __init setup_memory
 
setup_bootmem_allocator();
 }
+
+void __init zone_sizes_init(void)
+{
+   unsigned long zones_size[MAX_NR_ZONES] = {0, 0, 0};
+   unsigned int max_dma, high, low;
+
+   max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
+   low = max_low_pfn;
+   high = highend_pfn;
+
+   if (low < max_dma)
+   zones_size[ZONE_DMA] = low;
+   else {
+   zones_size[ZONE_DMA] = max_dma;
+   zones_size[ZONE_NORMAL] = low - max_dma;
+#ifdef CONFIG_HIGHMEM
+   zones_size[ZONE_HIGHMEM] = high - low;
+#endif
+   }
+   free_area_init(zones_size);
+}
 #else
 extern unsigned long setup_memory(void);
+extern void zone_sizes_init(void);
 #endif /* !CONFIG_DISCONTIGMEM */
 
 void __init setup_bootmem_allocator(void)
@@ -1194,6 +1216,24 @@ void __init setup_bootmem_allocator(void
 }
 
 /*
+ * The node 0 pgdat is initialized before all of these because
+ * it's needed for bootmem.  node>0 pgdats have their virtual
+ * space allocated before the pagetables are in place to access
+ * them, so they can't be cleared then.
+ *
+ * This should all compile down to nothing when NUMA is off.
+ */
+void __init remapped_pgdat_init(void)
+{
+   int nid;
+
+   for_each_online_node(nid) {
+   if (nid != 0)
+   memset(NODE_DATA(nid), 0, sizeof(struct pglist_data));
+   }
+}
+
+/*
  * Request address space for all standard RAM and ROM resources
  * and also for regions reported as reserved by the e820.
  */
@@ -1465,6 +1505,8 @@ void __init setup_arch(char **cmdline_p)
smp_alloc_memory(); /* AP processor realmode stacks in low memory*/
 #endif
paging_init();
+   remapped_pgdat_init();
+   zone_sizes_init();
 
/*
 * NOTE: at this point the bootmem allocator is fully available.
diff -puN arch/i386/mm/discontig.c~A2.1-re-memset-i386-pgdats 
arch/i386/mm/discontig.c
--- memhotplug/arch/i386/mm/discontig.c~A2.1-re-memset-i386-pgdats  
2005-01-25 13:04:30.0 -0800
+++ memhotplug-dave/arch/i386/mm/discontig.c2005-01-25 13:40:15.0 
-0800
@@ -135,7 +135,6 @@ static void __init allocate_pgdat(int ni
else {
NODE_DATA(nid) = (pg_data_t *)(__va(min_low_pfn << PAGE_SHIFT));
min_low_pfn += PFN_UP(sizeof(pg_data_t));
-   memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
}
 }
 
@@ -256,6 +255,7 @@ unsigned long __init setup_memory(void)
for_each_online_node(nid)
find_max_pfn_node(nid);
 
+   memset(NODE_DATA(0), 0, sizeof(struct pglist_data));
NODE_DATA(0)->bdata = _bdata;
 
 #ifdef CONFIG_KEXEC
@@ -286,8 +286,6 @@ void __init zone_sizes_init(void)
for (nid = MAX_NUMNODES - 1; nid >= 0; nid--) {
if (!node_online(nid))
continue;
-   if (nid)
-   memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
NODE_DATA(nid)->pgdat_next = pgdat_list;
pgdat_list = NODE_DATA(nid);
}
diff -puN include/asm-i386/mmzone.h~A2.1-re-memset-i386-pgdats 
include/asm-i386/mmzone.h
diff -puN mm/page_alloc.c~A2.1-re-memset-i386-pgdats mm/page_alloc.c
diff -puN arch/i386/mm/init.c~A2.1-re-memset-i386-pgdats arch/i386/mm/init.c
--- memhotplug/arch/i386/mm/init.c~A2.1-re-memset-i386-pgdats   2005-01-25 
13:04:30.0 -0800
+++ memhotplug-dave/arch/i386/mm/init.c 2005-01-25 13:41:01.0 

[PATCH 1/2] fix audit skb leak on congested netlink socket

[Chris Wright]

When auditd is congested the kernel's audit system leaks skb's.  First,
it takes them off the audit_buffer sklist at which point they are lost,
second, it allocates a new skb with 0 length payload.  Then (likely still
congested), it repeats this losing the new skb.  Plug the leak by making
sure to requeue the skb, and avoid audit_log_move() on 0 len audit_buffer.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

= kernel/audit.c 1.6 vs edited =
--- 1.6/kernel/audit.c  2005-01-20 20:56:04 -08:00
+++ edited/kernel/audit.c   2005-01-25 14:34:32 -08:00
@@ -494,6 +494,10 @@ static void audit_log_move(struct audit_
char*start;
int extra = ab->nlh ? 0 : NLMSG_SPACE(0);
 
+   /* possible resubmission */
+   if (ab->len == 0)
+   return;
+
skb = skb_peek(>sklist);
if (!skb || skb_tailroom(skb) <= ab->len + extra) {
skb = alloc_skb(2 * ab->len + extra, GFP_ATOMIC);
@@ -535,6 +539,7 @@ static inline int audit_log_drain(struct
}
if (retval == -EAGAIN && ab->count < 5) {
++ab->count;
+   skb_queue_tail(>sklist, skb);
audit_log_end_irq(ab);
return 1;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[Christoph Lameter]

On Tue, 25 Jan 2005, john stultz wrote:

> Agreed. I'll get something like this done for the next release.
>
> > Well, since it only contains the prescale and postscale offsets and the
> > scaling value, it only needs to be updated when they change, so a hook
> > here would be fine.
>
> Great, thats what I was hoping.

I just hope that the implementation of one arch does not become a standard
without sufficient reflection. Could we first get an explanation of
the rationale of the offsets? From my viewpoint of the ia64 implementation
I have some difficulty understanding why such complicated things as
prescale and postscale are necessary in gettimeday and why the simple
formula that we use in gettimeofday is not sufficient?

Frankly, the direction that the design of the new time subsystem is
taking is bothering me. Work on this on our part would just improve the
situation from drastically worse performance to somewhat worse. So far I
have not seen a benefit of moving away from the existing code base. For
the project to make sense it needs at least to be evident that the design
of the solution would lead to better timer performance in the long run.
Conceptually that seems so far not to be possible.

I'd love simplication of the timer subsystem through the use of
nanosecond offsets. However, the POSIX api always has extra fields
for seconds and nanoseconds and converting back and forth between the
internal representation in 64bit nanoseconds and the POSIX structures may
be another performance penalty since it involves divisions and remainder
processing.

What I think is a priority need is some subsystem that manages
time sources effectively (including the ability of the ntp code to
scale the appropriately) and does that in an arch independent
way so that all the code can be consolidated. Extract the best existing
solutions and work from there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 1/5] refactor i386 memory setup

[Dave Hansen]

Refactor the i386 default and CONFIG_DISCONTIG_MEM setup_memory()
functions to share the common bootmem initialisation code.  This code
is intended to be identical, but there are currently some fixes
applied to one and not the other.  This patch extracts this common
initialisation code.

Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 memhotplug-dave/arch/i386/kernel/setup.c |   28 ---
 memhotplug-dave/arch/i386/mm/discontig.c |  118 +--
 2 files changed, 21 insertions(+), 125 deletions(-)

diff -puN arch/i386/kernel/setup.c~B-sparse-060-refactor-setup_memory-i386 
arch/i386/kernel/setup.c
--- memhotplug/arch/i386/kernel/setup.c~B-sparse-060-refactor-setup_memory-i386 
2005-01-25 13:04:29.0 -0800
+++ memhotplug-dave/arch/i386/kernel/setup.c2005-01-25 13:44:28.0 
-0800
@@ -1000,8 +1000,6 @@ unsigned long __init find_max_low_pfn(vo
return max_low_pfn;
 }
 
-#ifndef CONFIG_DISCONTIGMEM
-
 /*
  * Free all available memory for boot time allocation.  Used
  * as a callback function by efi_memory_walk()
@@ -1075,15 +1073,15 @@ static void __init reserve_ebda_region(v
reserve_bootmem(addr, PAGE_SIZE);   
 }
 
+#ifndef CONFIG_DISCONTIGMEM
+void __init setup_bootmem_allocator(void);
 static unsigned long __init setup_memory(void)
 {
-   unsigned long bootmap_size, start_pfn, max_low_pfn;
-
/*
 * partially used pages are not usable - thus
 * we are rounding upwards:
 */
-   start_pfn = PFN_UP(init_pg_tables_end);
+   min_low_pfn = PFN_UP(init_pg_tables_end);
 
find_max_pfn();
 
@@ -1099,10 +1097,22 @@ static unsigned long __init setup_memory
 #endif
printk(KERN_NOTICE "%ldMB LOWMEM available.\n",
pages_to_mb(max_low_pfn));
+
+   setup_bootmem_allocator();
+
+   return max_low_pfn;
+}
+#else
+extern unsigned long setup_memory(void);
+#endif /* !CONFIG_DISCONTIGMEM */
+
+void __init setup_bootmem_allocator(void)
+{
+   unsigned long bootmap_size;
/*
 * Initialize the boot-time allocator (with low memory only):
 */
-   bootmap_size = init_bootmem(start_pfn, max_low_pfn);
+   bootmap_size = init_bootmem(min_low_pfn, max_low_pfn);
 
register_bootmem_low_pages(max_low_pfn);
 
@@ -1112,7 +1122,7 @@ static unsigned long __init setup_memory
 * the (very unlikely) case of us accidentally initializing the
 * bootmem allocator with an invalid RAM area.
 */
-   reserve_bootmem(HIGH_MEMORY, (PFN_PHYS(start_pfn) +
+   reserve_bootmem(HIGH_MEMORY, (PFN_PHYS(min_low_pfn) +
 bootmap_size + PAGE_SIZE-1) - (HIGH_MEMORY));
 
/*
@@ -1182,11 +1192,7 @@ static unsigned long __init setup_memory
}
}
 #endif
-   return max_low_pfn;
 }
-#else
-extern unsigned long setup_memory(void);
-#endif /* !CONFIG_DISCONTIGMEM */
 
 /*
  * Request address space for all standard RAM and ROM resources
diff -puN arch/i386/mm/discontig.c~B-sparse-060-refactor-setup_memory-i386 
arch/i386/mm/discontig.c
--- memhotplug/arch/i386/mm/discontig.c~B-sparse-060-refactor-setup_memory-i386 
2005-01-25 13:04:29.0 -0800
+++ memhotplug-dave/arch/i386/mm/discontig.c2005-01-25 13:42:10.0 
-0800
@@ -139,46 +139,6 @@ static void __init allocate_pgdat(int ni
}
 }
 
-/*
- * Register fully available low RAM pages with the bootmem allocator.
- */
-static void __init register_bootmem_low_pages(unsigned long system_max_low_pfn)
-{
-   int i;
-
-   for (i = 0; i < e820.nr_map; i++) {
-   unsigned long curr_pfn, last_pfn, size;
-   /*
-* Reserve usable low memory
-*/
-   if (e820.map[i].type != E820_RAM)
-   continue;
-   /*
-* We are rounding up the start address of usable memory:
-*/
-   curr_pfn = PFN_UP(e820.map[i].addr);
-   if (curr_pfn >= system_max_low_pfn)
-   continue;
-   /*
-* ... and at the end of the usable range downwards:
-*/
-   last_pfn = PFN_DOWN(e820.map[i].addr + e820.map[i].size);
-
-   if (last_pfn > system_max_low_pfn)
-   last_pfn = system_max_low_pfn;
-
-   /*
-* .. finally, did all the rounding and playing
-* around just make the area go away?
-*/
-   if (last_pfn <= curr_pfn)
-   continue;
-
-   size = last_pfn - curr_pfn;
-   free_bootmem_node(NODE_DATA(0), PFN_PHYS(curr_pfn), 
PFN_PHYS(size));
-   }
-}
-
 void __init remap_numa_kva(void)
 {
void *vaddr;
@@ -227,21 +187,11 @@ static unsigned long calculate_numa_rema
return reserve_pages;
 }
 
-/*
- * workaround for Dell 

[PATCH 2/2] some minor cleanups for audit_log_lost() messages

[Chris Wright]

Some minor cleanups for audit_log_lost() messages.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

= kernel/audit.c 1.7 vs edited =
--- 1.7/kernel/audit.c  2005-01-25 14:35:07 -08:00
+++ edited/kernel/audit.c   2005-01-25 14:35:54 -08:00
@@ -160,7 +160,7 @@ static void audit_panic(const char *mess
printk(KERN_ERR "audit: %s\n", message);
break;
case AUDIT_FAIL_PANIC:
-   panic(message);
+   panic("audit: %s\n", message);
break;
}
 }
@@ -663,10 +663,10 @@ struct audit_buffer *audit_log_start(str
 
if (!ab)
ab = kmalloc(sizeof(*ab), GFP_ATOMIC);
-   if (!ab)
-   audit_log_lost("audit: out of memory in audit_log_start");
-   if (!ab)
+   if (!ab) {
+   audit_log_lost("out of memory in audit_log_start");
return NULL;
+   }
 
atomic_inc(_backlog);
skb_queue_head_init(>sklist);
-
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 to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[J.A. Magallon]

On 2005.01.25, Zephaniah E. Hull wrote:
> On Tue, Jan 25, 2005 at 12:56:25PM +, J.A. Magallon wrote:
> 
> > You can use the latest drivers (6629) with this patches:
> > 
> > http://www.minion.de/files/1.0-6629/
> > 
> > They work fine up to -rc2.
> > 
> > If you want to use the driver with -mm, you have to kill the support
> > for AGPGART in nvidia driver, add -DNOAGPGART to EXTRA_CFLAGS in the
> > makefile. It will require a big change to use the multi-agp patches
> > in -mm. But you are restricted to those AGPs supported by nvidia
> > (ah, and don't load any agp related module...).
> 
> For values of big changes that equal the attached patch.
> 

Opps, previous patch was wrapped. Correct one attached.

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.10-jam6 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1

diff -ruN nv-6629-jam/src/nv/nv-linux.h nv-6629-jam-2/src/nv/nv-linux.h
--- nv-6629-jam/src/nv/nv-linux.h	2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/nv-linux.h	2005-01-26 00:25:10.0 +0100
@@ -930,6 +930,9 @@
 
 /* lock for linux-specific alloc queue */
 struct semaphore at_lock;
+
+	/* AGP bridge handle */
+	struct agp_bridge_data *agp_bridge;
 } nv_linux_state_t;
 
 
diff -ruN nv-6629-jam/src/nv/nv.c nv-6629-jam-2/src/nv/nv.c
--- nv-6629-jam/src/nv/nv.c	2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/nv.c	2005-01-26 00:47:14.0 +0100
@@ -3011,10 +3011,11 @@
 return -1;
 }
 #elif defined(AGPGART)
-int error;
-if ((error = agp_backend_acquire()) != -EINVAL)
+		nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
+		nvl->agp_bridge = agp_backend_acquire(nvl->dev);
+if (nvl->agp_bridge)
 {
-if (!error) agp_backend_release();
+agp_backend_release(nvl->agp_bridge);
 nv_printf(NV_DBG_WARNINGS,
   "NVRM: not using NVAGP, an AGPGART backend is loaded!\n");
 return -1;
diff -ruN nv-6629-jam/src/nv/os-agp.c nv-6629-jam-2/src/nv/os-agp.c
--- nv-6629-jam/src/nv/os-agp.c	2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/os-agp.c	2005-01-26 00:49:01.0 +0100
@@ -60,23 +60,23 @@
 #endif
 
 #if defined(KERNEL_2_6)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) agp_backend_acquire()
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) agp_enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) agp_backend_release()
-#define NV_AGPGART_COPY_INFO(o,p) agp_copy_info(p)
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) agp_allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) agp_free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) agp_bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) agp_unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ nvl->agp_bridge = agp_backend_acquire(nvl->dev); !nvl->agp_bridge; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) agp_enable(nvl->agp_bridge,mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) agp_backend_release(nvl->agp_bridge)
+#define NV_AGPGART_COPY_INFO(nvl,o,p) agp_copy_info(nvl->agp_bridge,p)
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type) agp_allocate_memory(nvl->agp_bridge,count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) agp_free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) agp_bind_memory(p,offset)
+#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) agp_unbind_memory(p)
 #elif defined(KERNEL_2_4)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) ({ (o)->acquire(); 0; })
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) (o)->enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) ((o)->release())
-#define NV_AGPGART_COPY_INFO(o,p) ({ (o)->copy_info(p); 0; })
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) (o)->allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) (o)->free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) (o)->bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) (o)->unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ (o)->acquire(); 0; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) (o)->enable(mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) ((o)->release())
+#define NV_AGPGART_COPY_INFO(nvl,o,p) ({ (o)->copy_info(p); 0; })
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type) (o)->allocate_memory(count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) (o)->free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) (o)->bind_memory(p,offset)
+#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) (o)->unbind_memory(p)
 #endif
 
 #endif /* AGPGART */
@@ -96,6 +96,7 @@
 U032  agp_fw;
 void *bitmap;
 U032 bitmap_size;
+	nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
 
 memset( (void *) , 0, sizeof(agp_gart));
 
@@ -110,7 +111,7 @@
  * the memory controller.
  */
 
-if (NV_AGPGART_BACKEND_ACQUIRE(drm_agp_p))
+if (NV_AGPGART_BACKEND_ACQUIRE(nvl,drm_agp_p))

[RFC][PATCH 2/5] consolidate set_max_mapnr_init() implementations

[Dave Hansen]

discontig.c has its own version of set_max_mapnr_init().  However,
all that it really does differently from the mm/init.c version is
skip setting max_mapnr (which doesn't exist because there's no 
mem_map[]).-

Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 memhotplug-dave/arch/i386/mm/discontig.c |9 -
 memhotplug-dave/arch/i386/mm/init.c  |   11 +++
 2 files changed, 7 insertions(+), 13 deletions(-)

diff -puN arch/i386/mm/init.c~A1.2-cleanup-set_max_mapnr_init 
arch/i386/mm/init.c
--- memhotplug/arch/i386/mm/init.c~A1.2-cleanup-set_max_mapnr_init  
2005-01-25 13:51:03.0 -0800
+++ memhotplug-dave/arch/i386/mm/init.c 2005-01-25 14:05:28.0 -0800
@@ -567,19 +567,22 @@ static void __init test_wp_bit(void)
}
 }
 
-#ifndef CONFIG_DISCONTIGMEM
 static void __init set_max_mapnr_init(void)
 {
 #ifdef CONFIG_HIGHMEM
-   max_mapnr = num_physpages = highend_pfn;
+   num_physpages = highend_pfn;
 #else
-   max_mapnr = num_physpages = max_low_pfn;
+   num_physpages = max_low_pfn;
+#endif
+#ifndef CONFIG_DISCONTIGMEM
+   max_mapnr = num_physpages;
 #endif
 }
+
+#ifndef CONFIG_DISCONTIGMEM
 #define __free_all_bootmem() free_all_bootmem()
 #else
 #define __free_all_bootmem() free_all_bootmem_node(NODE_DATA(0))
-extern void set_max_mapnr_init(void);
 #endif /* !CONFIG_DISCONTIGMEM */
 
 static struct kcore_list kcore_mem, kcore_vmalloc; 
diff -puN arch/i386/mm/discontig.c~A1.2-cleanup-set_max_mapnr_init 
arch/i386/mm/discontig.c
--- memhotplug/arch/i386/mm/discontig.c~A1.2-cleanup-set_max_mapnr_init 
2005-01-25 13:51:03.0 -0800
+++ memhotplug-dave/arch/i386/mm/discontig.c2005-01-25 13:57:32.0 
-0800
@@ -370,12 +370,3 @@ void __init set_highmem_pages_init(int b
totalram_pages += totalhigh_pages;
 #endif
 }
-
-void __init set_max_mapnr_init(void)
-{
-#ifdef CONFIG_HIGHMEM
-   num_physpages = highend_pfn;
-#else
-   num_physpages = max_low_pfn;
-#endif
-}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 5/5] do not unnecessarily memset the pgdats

[Dave Hansen]

Both the pgdats and the struct zonelist are zeroed unnecessarily.
The zonelist is a member of the pgdat, so any time the pgdat is
cleared, so is the zonelist.  All of the architectures present a
zeroed pgdat to the generic code, so it's not necessary to set it
again.

Not clearing it like this allows the functions to be reused by
the memory hotplug code.  The only architecture which has a
dependence on these clears is i386.  The previous patch in this
series fixed that up.

Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 arch/i386/mm/init.c |0 
 memhotplug-dave/mm/page_alloc.c |2 --
 2 files changed, 2 deletions(-)

diff -puN arch/i386/kernel/setup.c~A2.2-dont-memset-pgdats 
arch/i386/kernel/setup.c
diff -puN arch/i386/mm/discontig.c~A2.2-dont-memset-pgdats 
arch/i386/mm/discontig.c
diff -puN include/asm-i386/mmzone.h~A2.2-dont-memset-pgdats 
include/asm-i386/mmzone.h
diff -puN mm/page_alloc.c~A2.2-dont-memset-pgdats mm/page_alloc.c
--- memhotplug/mm/page_alloc.c~A2.2-dont-memset-pgdats  2005-01-25 
14:23:52.0 -0800
+++ memhotplug-dave/mm/page_alloc.c 2005-01-25 14:23:52.0 -0800
@@ -1488,7 +1488,6 @@ static void __init build_zonelists(pg_da
/* initialize zonelists */
for (i = 0; i < GFP_ZONETYPES; i++) {
zonelist = pgdat->node_zonelists + i;
-   memset(zonelist, 0, sizeof(*zonelist));
zonelist->zones[0] = NULL;
}
 
@@ -1535,7 +1534,6 @@ static void __init build_zonelists(pg_da
struct zonelist *zonelist;
 
zonelist = pgdat->node_zonelists + i;
-   memset(zonelist, 0, sizeof(*zonelist));
 
j = 0;
k = ZONE_NORMAL;
diff -puN arch/i386/mm/init.c~A2.2-dont-memset-pgdats arch/i386/mm/init.c
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[john stultz]

On Wed, 2005-01-26 at 10:53 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:
> 
> > The performance is a concern, and right now there are issues (ntp_scale
> > being the top of the list) however I hope they can be resolved. Looking
> > at ppc64's do_gettimeofday() vs this implementation there we do have
> > more overhead, but maybe you could suggest how we can avoid some of it?
> 
> I would suggest reclaculating the scale factor and offset for ntp
> adjustement regulary from the timer tick or so, not on each gettimeofday
> call.

Agreed. I'll get something like this done for the next release.


> Also, I have some updates to the ppc64 implementation where I regulary
> update the pre-scale offset into the post-scale one so that the
> timebase-prescale substraction always gives a 32 bits number. I do that
> so my fast userland gettimeofday can be implemented more easily and more
> efficiently for 32 bits processes. I yet have to check how I can hook
> those things into your new scheme.

Hmm. In my code, I move the interval delta (similar to your pre-scale
offset) to system_time (seems to be equivalent to the post-scale) at
each call to timeofday_interrupt_hook(). So while 64 bits are normally
used, you could probably get away doing the interval delta calculations
in 32bits if your timesource frequency isn't too large. This would only
be done in the arch-specific 32bit vsyscall code, right?

> > I still want to support vsyscall gettimeofday, although it does have to
> > be done on an arch-by-arch basis. It's likely the systemcfg data
> > structure can still be generated and exported. I'll look into it and see
> > what can be done.
> 
> Well, since it only contains the prescale and postscale offsets and the
> scaling value, it only needs to be updated when they change, so a hook
> here would be fine.

Great, thats what I was hoping.

thanks
-john

-
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] netdrv gianfar: Fix usage of gfar_read in debug code

[Kumar Gala]

Fixes instances where gfar_read() was invoked in debug codewith a value, 
rather than a pointer.

Signed-of-by: Andy Fleming <[EMAIL PROTECTED]>
Signed-of-by: Kumar Gala <[EMAIL PROTECTED]>

---

diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c
--- a/drivers/net/gianfar.c 2005-01-25 18:14:13 -06:00
+++ b/drivers/net/gianfar.c 2005-01-25 18:14:13 -06:00
@@ -1190,8 +1190,8 @@
} else {
 #ifdef VERBOSE_GFAR_ERRORS
printk(KERN_DEBUG "%s: receive called twice (%x)[%x]\n",
-  dev->name, gfar_read(priv->regs->ievent),
-  gfar_read(priv->regs->imask));
+  dev->name, gfar_read(>regs->ievent),
+  gfar_read(>regs->imask));
 #endif
}
 #else
@@ -1415,7 +1415,7 @@
 
 #ifdef VERBOSE_GFAR_ERRORS
printk(KERN_DEBUG "%s: busy error (rhalt: %x)\n", dev->name,
-  gfar_read(priv->regs->rstat));
+  gfar_read(>regs->rstat));
 #endif
}
if (events & IEVENT_BABR) {
@@ -1793,7 +1793,7 @@
 
 #ifdef VERBOSE_GFAR_ERRORS
printk(KERN_DEBUG "%s: busy error (rhalt: %x)\n", dev->name,
-  gfar_read(priv->regs->rstat));
+  gfar_read(>regs->rstat));
 #endif
}
if (events & IEVENT_BABR) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 0/5] consolidate i386 NUMA init code

[Dave Hansen]

The following five patches reorganize and consolidate some of the i386
NUMA/discontigmem code.  They grew out of some observations as we
produced the memory hotplug patches.

Only the first one is really necessary, as it makes the implementation
of one of the hotplug components much simpler and smaller.  2 and 3 came
from just looking at the effects on the code after 1.

4 and 5 aren't absolutely required for hotplug either, but do allow
sharing a bunch of code between the normal boot-time init and hotplug
cases.  

These are all on top of 2.6.11-rc2-mm1.

-- Dave

-
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] Use MM_VM_SIZE in exit_mmap

[Nick Piggin]

[Hi, please cc Andi on 4 level page tables stuff too]
Anton Blanchard wrote:
Hi,
The 4 level pagetable code changed the exit_mmap code to rely on
TASK_SIZE. On some architectures (eg ppc64 and ia64), this is a per task
property and bad things can happen in certain circumstances when using
it.
It is possible for one task to end up "owning" an mm from another - we
have seen this with the procfs code when process 1 accesses
/proc/pid/cmdline of process 2 while it is exiting.  Process 2 exits
but does not tear its mm down. Later on process 1 finishes with the proc
file and the mm gets torn down at this point.
Now if process 1 was 32bit and process 2 was 64bit then we end up using
a bad value for TASK_SIZE in exit_mmap. We only tear down part of the
address space and leave half initialised pagetables and entries in the
MMU etc.
MM_VM_SIZE() was created for this purpose (and is used in the next line
for tlb_finish_mmu), so use it. I moved the PGD round up of TASK_SIZE
into the default MM_VM_SIZE.
Yep, looks like the right thing to do. I don't know about moving the
rounding into MM_VM_SIZE though - it is basically just a requirement of
clear_page_range. Might be better to leave it there?
As an aside, all architectures except one define FIRST_USER_PGD_NR as 0:
include/asm-arm26/pgtable.h:#define FIRST_USER_PGD_NR   1
It would be nice to get rid of one more magic constant and just clear
from 0 ... MM_VM_SIZE(). That would make it consistent with the
tlb_flush_mmu call below it too.
Considering the comments by Ian and Russell, can we remove the special
casing by going in the other direction; feed FIRST_USER_PGD_NR * PGDIR_SIZE
to tlb_finish_mmu? Ian, Russell, this would only be a change to your
architectures... so long as your tlb_finish_mmu isn't doing something
special when it sees a zero argument AFAIKS that would be OK?
-
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: thoughts on kernel security issues

[Bill Davidsen]

On Tue, 25 Jan 2005, John Richard Moser wrote:


> Thus, by having fewer exploits available, fewer successful attacks
> should happen due to the laws of probability.  So the goal becomes to
> fix as many bugs as possible, but also to mitigate the ones we don't
> know about.  To truly mitigate any security flaw, we must make a
> non-circumventable protection.

To the extent that this means "if you see a bug, fix the bug, even if it's
unrelated" I agree completely.

-- 
bill davidsen <[EMAIL PROTECTED]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
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 space out of memory approach

[Mauricio Lin]

Hi Thomaz,

On Tue, 25 Jan 2005 22:39:39 +0100, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-01-25 at 17:13 -0400, Mauricio Lin wrote:
> > Hi Andrea,
> >
> > Your OOM Killer patch was tested and a strange behaviour was found.
> > Basically as normal user we started some applications as openoffice,
> > mozilla and emacs.
> > And as a root (in another tty) we started a simple program that uses
> > malloc in a forever loop as below:
> >
> > int main (void)
> > {
> >   int * mem;
> >   for (;;)
> > mem = (int *) malloc(sizeof(int));
> >   return 0;
> > }
> >
> >
> > Using the original OOM Killer, malloc is the first killed application
> > and the sytem is restored in a useful state. After applying your patch
> > and accomplish the same experiment, the OOM Killer it does not kill
> > malloc program and it enters in a kind of forever loop as below:
> >
> > 1) out_of_memory is invoked;
> > 2) select_bad_process is invoked;
> 
> Which process is selected ?
Sometimes the first application to be killed is XFree. AFAIK the
malloc is never killed, because the OOM Killer does not stop to do its
work. Usually we are not able to check the kernel log file after
rebooting the system. Because nothing was written there (perhaps
syslogd or klogd were killed during OOM). But I can see the printk
messages on the screen during OOM Killer action. This does not happen
with original OOM Killer.

I put some printk in order to trace the OOM Killer and IMHO what is going is:

out_of_memory function is invoked and after that the
select_bad_process is also invoked.
So its starts to point each task. But during the do_each_thread /
while each_thread loop the
condition:

if ((unlikely(test_tsk_thread_flag(p, TIF_MEMDIE)) || (p->flags &
PF_EXITING)) &&
!(p->flags & PF_DEAD))
   return ERR_PTR(-1UL);

is true and it leaves from select_bad_process function because of the
return statement.

So the running code return from the point that select_bad_process was
called, i.e., in the out_of_memory function. The condition statement
in out_of_memory function:

if (PTR_ERR(p) == -1UL)
goto out;

is also true so it goes to "out" label and leaves from the
out_of_memory function. But because of the OOM state the out_of_memory
function is invoked again and after that the select_bad_process is
also invoked again. And during the do_each_thread / while each_thread
loop the same condition as mentioned above is true again. So it leaves
from select_bad_process function because of the return statement and
goes to "out" label and
leaves from the out_of_memory function again. This behaviour is
repeated continuously
during a long time until I stop waiting and reboot the system using my
own finger.

> Can you please show the kernel messages ?

OK. We will try to reach a situation that the printk messages can be
written entirely in the log file and show you the kernel messages. But
as I said: usually the printks messages are not written in the log
file using Andrea's patch. But using the original OOM Killer we can
see the messages in the log file. The syslog.conf file is the same for
both OOM Killer(Andrea and Original). Do you have any idea what is
happening to log file?

If you do not mind, you can accomplish the same test case as I
mentioned on my last email. I would like to know if this problem
happens to others people as well.

We tested on the laptop and desktop machines with 128MB of RAM and
swap space disabled.


BR,

Mauricio Lin.
-
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: swap is never used on ultrasparc64/32 - 2.6.11-rc2 (STILL NOT SOLVED)

[René Rebe]

Hi,
On 25. Jan 2005, at 18:40 Uhr, Grzegorz Piotr Jaskiewicz wrote:
[...]
I can confirm this. What is your last kernel that worked? I have no 
data at hand - but I'm sure in either 2.6.8 or 2.6.10 swapping did 
work.

Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.exactcode.de/t2
+49 (0)30  255 897 45
-
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] Use MM_VM_SIZE in exit_mmap

[Anton Blanchard]

 
Hi,

> I don't think Anton can count.  (and for some reason I seem to be missing
> his mail at the moment.)
> 
> include/asm-arm/pgtable.h:#define FIRST_USER_PGD_NR 1
> 
> there's two.  FIRST_USER_PGD_NR was created specifically for ARM because
> many of our CPUs place their hardware vector tables at *virtual* address
> zero.  Unmapping this virtual page would be rather bad for the system -
> consider the effect of unmapping the code for *all* CPU exceptions.

It does look like I have trouble counting past 1 :) Lets forget that
proposal, it was just a minor cleanup anyway.

Anton
-
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/4] page_cache_readahead: remove duplicated code

[Ram]

On Tue, 2005-01-25 at 03:59, Oleg Nesterov wrote:
> Cases "no ahead window" and "crossed into ahead window"
> can be unified.


No. There is a reason why we had some duplication. With your patch,
we will end up reading-on-demand instead of reading ahead.

When we notice a sequential reads have resumed, we first read in the
data that is requested. 
However if the read request is for more pages than what are being held
in the current window, we make the ahead window as the current window
and read in more pages in the ahead window. Doing that gives the
opportunity of always having pages in the ahead window when the next
sequential read request comes in.  If we apply this patch, we will
always have to read the pages that are being requested instead of
satisfying them from the ahead window.

Ok, if this does not make it clear, here is another way of proving that
your patch does not exactly behave the way it did earlier.

With your patch you will have only one call to
block_page_cache_readahead(), when earlier there could be cases where
block_page_cache_readahead() could be called twice.

Am I am making sense?
RP
 

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

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:

> The performance is a concern, and right now there are issues (ntp_scale
> being the top of the list) however I hope they can be resolved. Looking
> at ppc64's do_gettimeofday() vs this implementation there we do have
> more overhead, but maybe you could suggest how we can avoid some of it?

I would suggest reclaculating the scale factor and offset for ntp
adjustement regulary from the timer tick or so, not on each gettimeofday
call.

Also, I have some updates to the ppc64 implementation where I regulary
update the pre-scale offset into the post-scale one so that the
timebase-prescale substraction always gives a 32 bits number. I do that
so my fast userland gettimeofday can be implemented more easily and more
efficiently for 32 bits processes. I yet have to check how I can hook
those things into your new scheme.

> I still want to support vsyscall gettimeofday, although it does have to
> be done on an arch-by-arch basis. It's likely the systemcfg data
> structure can still be generated and exported. I'll look into it and see
> what can be done.

Well, since it only contains the prescale and postscale offsets and the
scaling value, it only needs to be updated when they change, so a hook
here would be fine.

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 to enable Nvidia v5336 on v2.6.11 kernel (was Re: inter_module_get and __symbol_get)

[J.A. Magallon]

On 2005.01.25, Zephaniah E. Hull wrote:
> On Tue, Jan 25, 2005 at 12:56:25PM +, J.A. Magallon wrote:
> 
> > You can use the latest drivers (6629) with this patches:
> > 
> > http://www.minion.de/files/1.0-6629/
> > 
> > They work fine up to -rc2.
> > 
> > If you want to use the driver with -mm, you have to kill the support
> > for AGPGART in nvidia driver, add -DNOAGPGART to EXTRA_CFLAGS in the
> > makefile. It will require a big change to use the multi-agp patches
> > in -mm. But you are restricted to those AGPs supported by nvidia
> > (ah, and don't load any agp related module...).
> 
> For values of big changes that equal the attached patch.
> 
> I'm using it on 2.6.10-mm3.  I sent it to Zander however since there is
> no way to detect the new multi-agp support barring some sick hacks it
> has not gone in.
> 
> It may conflict with the support for the 2.6.11-rc kernels, in which
> case when I next upgrade I'll find out and write a new one.
> > 
> > Ah, just a ton of workarounds
> 

Hay, that gave me the clues I was missing !!!
With patch below, I get 6629 working on 2.6.10-rc2-mm1. Apply it on top of
all the patches in the link above.

I know, it is ugly as hell (all those superfluos parameters in NV_AGPGART
macros, unused drm_agp_p...), but perhaps someone  will rework all that
macro mesh. For the moment, it works

diff -ruN nv-6629-jam/src/nv/nv-linux.h nv-6629-jam-2/src/nv/nv-linux.h
--- nv-6629-jam/src/nv/nv-linux.h   2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/nv-linux.h 2005-01-26 00:25:10.0 +0100
@@ -930,6 +930,9 @@
 
 /* lock for linux-specific alloc queue */
 struct semaphore at_lock;
+
+   /* AGP bridge handle */
+   struct agp_bridge_data *agp_bridge;
 } nv_linux_state_t;
 
 
diff -ruN nv-6629-jam/src/nv/nv.c nv-6629-jam-2/src/nv/nv.c
--- nv-6629-jam/src/nv/nv.c 2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/nv.c   2005-01-26 00:47:14.0 +0100
@@ -3011,10 +3011,11 @@
 return -1;
 }
 #elif defined(AGPGART)
-int error;
-if ((error = agp_backend_acquire()) != -EINVAL)
+   nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
+   nvl->agp_bridge = agp_backend_acquire(nvl->dev);
+if (nvl->agp_bridge)
 {
-if (!error) agp_backend_release();
+agp_backend_release(nvl->agp_bridge);
 nv_printf(NV_DBG_WARNINGS,
   "NVRM: not using NVAGP, an AGPGART backend is 
loaded!\n");
 return -1;
diff -ruN nv-6629-jam/src/nv/os-agp.c nv-6629-jam-2/src/nv/os-agp.c
--- nv-6629-jam/src/nv/os-agp.c 2005-01-24 23:16:46.0 +0100
+++ nv-6629-jam-2/src/nv/os-agp.c   2005-01-26 00:49:01.0 +0100
@@ -60,23 +60,23 @@
 #endif
 
 #if defined(KERNEL_2_6)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) agp_backend_acquire()
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) agp_enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) agp_backend_release()
-#define NV_AGPGART_COPY_INFO(o,p) agp_copy_info(p)
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) 
agp_allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) agp_free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) agp_bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) agp_unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ nvl->agp_bridge = 
agp_backend_acquire(nvl->dev); !nvl->agp_bridge; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) agp_enable(nvl->agp_bridge,mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) agp_backend_release(nvl->agp_bridge)
+#define NV_AGPGART_COPY_INFO(nvl,o,p) agp_copy_info(nvl->agp_bridge,p)
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type) 
agp_allocate_memory(nvl->agp_bridge,count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) agp_free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) agp_bind_memory(p,offset)
+#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) agp_unbind_memory(p)
 #elif defined(KERNEL_2_4)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) ({ (o)->acquire(); 0; })
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) (o)->enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) ((o)->release())
-#define NV_AGPGART_COPY_INFO(o,p) ({ (o)->copy_info(p); 0; })
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type) 
(o)->allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) (o)->free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) (o)->bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) (o)->unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ (o)->acquire(); 0; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) (o)->enable(mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) ((o)->release())
+#define NV_AGPGART_COPY_INFO(nvl,o,p) ({ (o)->copy_info(p); 0; })
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type) 
(o)->allocate_memory(count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) (o)->free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) 

Re: [RFC] shared subtrees

[Mike Waychison]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

J. Bruce Fields wrote:
> On Tue, Jan 25, 2005 at 04:47:04PM -0500, Mike Waychison wrote:
> 
>>Although Al hasn't explicitly defined the semantics for mount
>>- --make-shared, I think the idea is that 'only' that mountpoint becomes
>>tagged as shared (becomes a member of a p-node of size 1).
> 
> 
> On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote:
> 
>>  * we can mark a subtree sharable.  Every vfsmount in the subtree
>>that is not already in some p-node gets a single-element p-node of its
>>own.
> 
> 
> Also, note that mount automatically sets up propagation that mirrors
> that of the mounted on vfsmount, so by default new mounts anywhere in
> the subtree will also be tagged as shared.
> 

Why not simply call this --make-rshared and keep --make-shared only
share a single mount then?

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9tzDdQs4kOxk3/MRAp3jAJ9CjPjEQs1jvcm92Q2jAizYvnBOSgCeJ9A0
Jt0d1v7iLB3EPbEWq9r6zik=
=3u5S
-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: LKCD on 2.6 IA64 Linux Kernel

[Gerald Pfeifer]

On Tue, 25 Jan 2005 [EMAIL PROTECTED] wrote:
> I tried using lkcd on a ia64 machine running on 2.6.5-7.111 SuSe Kernel for
> debugging.

I strongly recommend you switch to 2.6.5-7.139 (or later) which is the
SLES9 SP1 kernel as opposed to the SLES9 GA kernel.  The former has quite
some changes wrt. LKCD and SLES9 SP1 also comes with a updated lkcdutils.

Furthermore, this is probably more of an issue you may want to discuss 
with your contacts at SUSE/Novell rather than on the linux-ia64 list,
though if there's interest I'll be happy to post pointers to these kernel
and lkcdutils packages.

Gerald
-
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: driver model u32 -> pm_message_t conversion: help needed

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 20:47 +0100, Pavel Machek wrote:
> Hi!
> 
> Two Long time ago, BenH said that making patches is easy, so I hope to
> get his help now... And will probably need more.

I will. I'm still a bit dealing with backlog of stuffs after my long
vacations, but I will asap.

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: Problem with cpu_rest() change

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 10:01 +0100, Ingo Molnar wrote:

> it can be bad for the idle task to hold the BKL and to have preemption
> enabled - in such a situation the scheduler will get confused if an
> interrupt triggers a forced preemption in that small window. But it's
> not necessary to keep IRQs disabled after the BKL has been dropped. In
> fact i think IRQ-disabling doesnt have to be done at all, the patch
> below ought to solve this scenario equally well, and should solve the
> PPC side-effects too.
> 
> Tested ontop of 2.6.11-rc2 on x86 PREEMPT+SMP and PREEMPT+!SMP (which
> IIRC were the config variants that triggered the original problem), on
> an SMP and on a UP system.

Excellent, thanks.

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: wait_for_completion API extension addition

[Mike Waychison]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ingo Molnar wrote:
> * Mike Waychison <[EMAIL PROTECTED]> wrote:
> 
> 
>>Hi Ingo,
>>
>>I noticed that the wait_for_completion API extensions made it into
>>mainline.
>>
>>However, I posted that the patch in question is broken a while back:
>>
>>http://marc.theaimsgroup.com/?l=linux-kernel=110131832828126=2
>>
>>Can we fix this?
> 
> 
> (/me pokes himself in the eyes)
> 
> could you send an incremental patch against BK-curr?
> 
>   Ingo


Attached.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB9tpBdQs4kOxk3/MRArUtAJ4+O7CCH8HdGqeREJb7yVQjOdJSkQCfRTIX
al9JVahdnQcOJIwyIW3LeDU=
=zhk+
-END PGP SIGNATURE-
Fix up signal_pending and timeout paths for wait_for_completion API extensions.

Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>

---

 sched.c |   21 +
 1 files changed, 13 insertions(+), 8 deletions(-)

Index: linux-2.6-bk-curr/kernel/sched.c
===
--- linux-2.6-bk-curr.orig/kernel/sched.c	2005-01-25 18:22:04.667957792 -0500
+++ linux-2.6-bk-curr/kernel/sched.c	2005-01-25 18:38:54.421451928 -0500
@@ -3020,15 +3020,17 @@ wait_for_completion_timeout(struct compl
 			__set_current_state(TASK_UNINTERRUPTIBLE);
 			spin_unlock_irq(>wait.lock);
 			timeout = schedule_timeout(timeout);
-			if (!timeout)
-goto out;
 			spin_lock_irq(>wait.lock);
+			if (!timeout) {
+__remove_wait_queue(>wait, );
+goto out;
+			}
 		} while (!x->done);
 		__remove_wait_queue(>wait, );
 	}
 	x->done--;
-	spin_unlock_irq(>wait.lock);
 out:
+	spin_unlock_irq(>wait.lock);
 	return timeout;
 }
 EXPORT_SYMBOL(wait_for_completion_timeout);
@@ -3048,6 +3050,7 @@ int fastcall __sched wait_for_completion
 		do {
 			if (signal_pending(current)) {
 ret = -ERESTARTSYS;
+__remove_wait_queue(>wait, );
 goto out;
 			}
 			__set_current_state(TASK_INTERRUPTIBLE);
@@ -3080,21 +3083,23 @@ wait_for_completion_interruptible_timeou
 		do {
 			if (signal_pending(current)) {
 timeout = -ERESTARTSYS;
-goto out_unlock;
+__remove_wait_queue(>wait, );
+goto out;
 			}
 			__set_current_state(TASK_INTERRUPTIBLE);
 			spin_unlock_irq(>wait.lock);
 			timeout = schedule_timeout(timeout);
-			if (!timeout)
-goto out;
 			spin_lock_irq(>wait.lock);
+			if (!timeout) {
+__remove_wait_queue(>wait, );
+goto out;
+			}
 		} while (!x->done);
 		__remove_wait_queue(>wait, );
 	}
 	x->done--;
-out_unlock:
-	spin_unlock_irq(>wait.lock);
 out:
+	spin_unlock_irq(>wait.lock);
 	return timeout;
 }
 EXPORT_SYMBOL(wait_for_completion_interruptible_timeout);

Re: [PATCH 4/7] posix-timers: CPU clock support for POSIX timers

[Christoph Lameter]

On Tue, 25 Jan 2005, George Anzinger wrote:

> > Your patch breaks the mmtimer driver because it used k_itimer values for
> > its own purposes. Here is a fix by defining an additional structure
> > in k_itimer (same approach for mmtimer as the cpu timers):
>
> I would like to get a read on the following defines...
> #define mmclock mmtimer.clock
> #define mmnode  mmtimer.node
> #define mmincr  mmtimer.incr
> #define mmexpires mmtimer.expires
>
> Then, of course, you would use the defines instead of the "." references.  Is
> this a big no-no in kernel code.  Seems to me it makes things a bit easier to 
> read.

Less code to get to the values would be preferable. Maybe this could be
another patch to clean up the clock driver stuff and provide some
standardized mechanism to provide private data space for future clock
drivers?

-
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: How to add/drop SCSI drives from within the driver?

[Mukker, Atul]

Thanks for the suggestion. After more exploration, looks like different
distribution have different implementations for /sbin/hotplug. This may
aggravate the issue for applications. For now, we will stick with a wait and
watch after bus scan :-(

Will probe the [EMAIL PROTECTED] list for more
pointers

Thanks

===
Atul Mukker
Architect, Drivers and BIOS
LSI Logic Corporation


> -Original Message-
> From: Patrick Mansfield [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 25, 2005 11:52 AM
> To: Mukker, Atul
> Cc: 'James Bottomley'; Linux Kernel; SCSI Mailing List
> Subject: Re: How to add/drop SCSI drives from within the driver?
> 
> Atul -
> 
> On Tue, Jan 25, 2005 at 11:27:36AM -0500, Mukker, Atul wrote:
> > After writing the "- - -" to the scan attribute, the management 
> > applications assume the udev has created the relevant 
> entries in the 
> > /dev directly and try to use the devices _immediately_ and 
> fail to see 
> > the devices
> > 
> > Is there a hotplug event which would tell the management 
> applications 
> > that the device nodes have actually been created now and 
> ready to be used?
> 
> Read the udev man page section, the part right before 
> "FILES". Try putting a script under /etc/dev.d/default/*.dev. 
> Then you can get more specific with an /etc/dev.d/scsi/*.dev 
> script or something else.
> 
> I just tried something simple but did not get it working.
> 
> Try [EMAIL PROTECTED] list for help.
> 
> -- Patrick Mansfield
> 
-
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: 2.6.11-rc2 and -rc1 hang during boot on PowerMacs

[Benjamin Herrenschmidt]

On Tue, 2005-01-25 at 09:56 +0100, Mikael Pettersson wrote:

> On the eMac:
> /proc/sys/kernel/powersave-nap exists and contains "0".
> /proc/device-tree/cpus/PowerPC,G4/flush-on-lock exists as an empty file.

Ok, that is weird... so for some reason, Apple decided not to allow the
eMac to do NAP mode, and thus to power manage the CPU when idle...

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] Use MM_VM_SIZE in exit_mmap

[Russell King]

On Tue, Jan 25, 2005 at 11:02:10PM +, Ian Molton wrote:
> Anton Blanchard wrote:
> 
>  > As an aside, all architectures except one define FIRST_USER_PGD_NR as 0:
>  >
>  > include/asm-arm26/pgtable.h:#define FIRST_USER_PGD_NR   1

I don't think Anton can count.  (and for some reason I seem to be missing
his mail at the moment.)

include/asm-arm/pgtable.h:#define FIRST_USER_PGD_NR 1

there's two.  FIRST_USER_PGD_NR was created specifically for ARM because
many of our CPUs place their hardware vector tables at *virtual* address
zero.  Unmapping this virtual page would be rather bad for the system -
consider the effect of unmapping the code for *all* CPU exceptions.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
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/7] posix-timers: CPU clock support for POSIX timers

[George Anzinger]

Christoph Lameter wrote:
On Mon, 24 Jan 2005, Christoph Lameter wrote:

It would be great to have a kind of private field that other clocks (like
clock drivers) could use for their purposes. mmtimer f.e. does use some
of the fields for the tick based timers for its purposes.

On that note:
Your patch breaks the mmtimer driver because it used k_itimer values for
its own purposes. Here is a fix by defining an additional structure
in k_itimer (same approach for mmtimer as the cpu timers):
I would like to get a read on the following defines...
#define mmclock mmtimer.clock
#define mmnode  mmtimer.node
#define mmincr  mmtimer.incr
#define mmexpires mmtimer.expires
Then, of course, you would use the defines instead of the "." references.  Is 
this a big no-no in kernel code.  Seems to me it makes things a bit easier to read.

George
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.10/include/linux/posix-timers.h
===
--- linux-2.6.10.orig/include/linux/posix-timers.h  2005-01-25 
14:35:11.0 -0800
+++ linux-2.6.10/include/linux/posix-timers.h   2005-01-25 14:35:16.0 
-0800
@@ -57,6 +57,12 @@ struct k_itimer {
unsigned long incr; /* interval in jiffies */
} real;
struct cpu_timer_list cpu;
+   struct {
+   unsigned int clock;
+   unsigned int node;
+   unsigned long incr;
+   unsigned long expires;
+   } mmtimer;
} it;
 };
#define mmclock mmtimer.clock
#define mmnode  mmtimer.node
#define mmincr  mmtimer.incr
#define mmexpires mmtimer.expires
Index: linux-2.6.10/drivers/char/mmtimer.c
===
--- linux-2.6.10.orig/drivers/char/mmtimer.c2005-01-25 14:35:09.0 
-0800
+++ linux-2.6.10/drivers/char/mmtimer.c 2005-01-25 14:34:41.0 -0800
@@ -420,19 +420,19 @@ static int inline reschedule_periodic_ti
int n;
struct k_itimer *t = x->timer;
-   t->it_timer.magic = x->i;
+   t->it.mmtimer.clock = x->i;
t->it_overrun--;
n = 0;
do {
-   t->it_timer.expires += t->it_incr << n;
+   t->it.mmtimer.expires += t->it.mmtimer.incr << n;
t->it_overrun += 1 << n;
n++;
if (n > 20)
return 1;
-   } while (mmtimer_setup(x->i, t->it_timer.expires));
+   } while (mmtimer_setup(x->i, t->it.mmtimer.expires));
return 0;
 }
@@ -468,7 +468,7 @@ mmtimer_interrupt(int irq, void *dev_id,
spin_lock([i].lock);
if (base[i].cpu == smp_processor_id()) {
if (base[i].timer)
-   expires = base[i].timer->it_timer.expires;
+   expires = base[i].timer->it.mmtimer.expires;
/* expires test won't work with shared irqs */
if ((mmtimer_int_pending(i) > 0) ||
(expires && (expires < rtc_time( {
@@ -505,7 +505,7 @@ void mmtimer_tasklet(unsigned long data)
t->it_overrun++;
}
-   if(t->it_incr) {
+   if(t->it.mmtimer.incr) {
/* Periodic timer */
if (reschedule_periodic_timer(x)) {
printk(KERN_WARNING "mmtimer: unable to reschedule\n");
@@ -513,7 +513,7 @@ void mmtimer_tasklet(unsigned long data)
}
} else {
/* Ensure we don't false trigger in mmtimer_interrupt */
-   t->it_timer.expires = 0;
+   t->it.mmtimer.expires = 0;
}
t->it_overrun_last = t->it_overrun;
 out:
@@ -524,7 +524,7 @@ out:
 static int sgi_timer_create(struct k_itimer *timer)
 {
/* Insure that a newly created timer is off */
-   timer->it_timer.magic = TIMER_OFF;
+   timer->it.mmtimer.clock = TIMER_OFF;
return 0;
 }
@@ -535,8 +535,8 @@ static int sgi_timer_create(struct k_iti
  */
 static int sgi_timer_del(struct k_itimer *timr)
 {
-   int i = timr->it_timer.magic;
-   cnodeid_t nodeid = timr->it_timer.data;
+   int i = timr->it.mmtimer.clock;
+   cnodeid_t nodeid = timr->it.mmtimer.node;
mmtimer_t *t = timers + nodeid * NUM_COMPARATORS +i;
unsigned long irqflags;
@@ -544,8 +544,8 @@ static int sgi_timer_del(struct k_itimer
spin_lock_irqsave(>lock, irqflags);
mmtimer_disable_int(cnodeid_to_nasid(nodeid),i);
t->timer = NULL;
-   timr->it_timer.magic = TIMER_OFF;
-   timr->it_timer.expires = 0;
+   timr->it.mmtimer.clock = TIMER_OFF;
+   timr->it.mmtimer.expires = 0;
spin_unlock_irqrestore(>lock, irqflags);
}
return 0;
@@ -558,7 +558,7 @@ static int 

Re: [PATCH 2/3] buffer writes to sysfs

[Mitch Williams]

On Mon, 24 Jan 2005, Greg KH wrote:
>
> Who is trying to send > 1K to a sysfs file?  Remember, sysfs files are
> for 1 value only.  If you consider > 1K a "single value" please point me
> to that part of the kernel that does that.
>
> > To the typical user, there's really no difference in behavior, unless
> you
> > are writing a ton of data into the file.  Of course, there's the
> obvious
> > question of why you'd want to do so...
>
> Exactly, you should not be doing that anyway.  So, because of that, I
> really don't want/like this patch.


OK, I've had a day to think about this, and I think I have a good answer
now.

Leaving aside the issue of how big a 'single object' is, we still have to
consider the possibility that a user _will_ indeed someday try to write 4K
(or more) to a sysfs file.  It's just going to happen.  And right now, the
kernel's behavior in that event is unpredictable, because we don't know
how the c library is going to buffer this write.

Right now, on my FC3 box, writing a large amount of data to a sysfs file
results in multiple writes of 1K to the file.  What my store method sees
then is multiple calls, each with 1K of data.  Each time, I have to assume
what I see is the complete contents of the write, and I have to process it
as such.

So if my sysfs file contains FOO, and the user writes BAR followed by 3k
of garbage, I'm not going to end up with FOO, or even BAR, but I'll end up
with whatever garbage I see at the beginning of the third 1K write.

The real problem is not that I get wrong values -- my store method should
handle this -- but that there are no errors returned from this operation.
The only way the user can tell that something is wrong is if a) I write a
message to the log telling what I did in my store method, and b) the user
checks the log.

My original write buffering patch fixes this problem, and allows up to 4K
to be consolidated into a single call to the store method.  It doesn't
seem to affect normal operation of my test system (nor those in our test
lab), but does hide error code returns from store methods.  And I can see
why you would be disinclined to accept such a patch.

While we may want to consider the possibility that a 'single object' may
someday grow large (crypto key maybe?), I can live without write buffering
right now.

But at the very least, we still need to handle this failure case.   I've
tested the following patch and it does resolve the issue.  However, it now
limits the size of sysfs writes to the size of the c library's buffer.



This patch returns an error code if the user trys to write data to a sysfs
file at any offset other than 0.

Signed-off-by:  Mitch Williams <[EMAIL PROTECTED]>

diff -urpN -X dontdiff linux-2.6.11-clean/fs/sysfs/file.c 
linux-2.6.11/fs/sysfs/file.c
--- linux-2.6.11-clean/fs/sysfs/file.c  2004-12-24 13:33:50.0 -0800
+++ linux-2.6.11/fs/sysfs/file.c2005-01-25 10:47:15.0 -0800
@@ -232,6 +232,8 @@ sysfs_write_file(struct file *file, cons
 {
struct sysfs_buffer * buffer = file->private_data;

+if (*ppos > 0)
+return -EIO;
down(>sem);
count = fill_write_buffer(buffer,buf,count);
if (count > 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: Drive missing only with LVM kernel

[Andre Tomt]

Jasper Koolhaas wrote:
As soon as the system had booted hdg has completely vanished, even in
single user mode:
# ls /dev/hd* /dev/sd*
/dev/hda   /dev/hda3  /dev/hdc1  /dev/hde   /dev/hde3  /dev/sda2  /dev/sdb1
/dev/hda1  /dev/hda4  /dev/hdc2  /dev/hde1  /dev/sda   /dev/sda3  /dev/sdb2
/dev/hda2  /dev/hdc   /dev/hdc3  /dev/hde2  /dev/sda1  /dev/sdb   /dev/sdb3
But the RAID is working just fine:
cd /dev && ./MAKEDEV hdg
In normal operation md-raid adresses the drive "internally", not via /dev.
-
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/7] posix-timers: CPU clock support for POSIX timers

[Roland McGrath]

> Possibly you could bury these name changes in defines.  I suspect the
> code would be easier to read and that we really don't need to be reminded
> that it is a union on each reference.

To be honest, I can never really predict the direction of vitriolic opinion
I'll get on such things.  I'm happy to change it however people prefer.


Thanks,
Roland
-
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/7] posix-timers: tidy up clock interfaces and consolidate dispatch logic

[Roland McGrath]

> We do need to do one or the other.  I assume the current indecision is
> pending some benchmarking work?

That was more or less the idea.  But I kind of figured someone would just
tell me which one to do without actually doing any timings.  This patch
(applies after the cpuclocks patch) makes the one decision, to use
conditional branches rather than indirect calls in the common case.
That is consistent with what the old code did.  


Thanks,
Roland


Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>

--- linux-2.6/kernel/posix-timers.c
+++ linux-2.6/kernel/posix-timers.c
@@ -185,31 +185,12 @@ static inline void unlock_timer(struct k
 }
 
 /*
- * Define this to initialize every k_clock function table so all its
- * function pointers are non-null, and always do indirect calls through the
- * table.  Leave it undefined to instead leave null function pointers and
- * decide at the call sites between a direct call (maybe inlined) to the
- * default function and an indirect call through the table when it's filled
- * in.  Which style is preferable is whichever performs better in the
- * common case of using the default functions.
- *
-#define CLOCK_DISPATCH_DIRECT
+ * Call the k_clock hook function if non-null, or the default function.
  */
-
-#ifdef CLOCK_DISPATCH_DIRECT
 #define CLOCK_DISPATCH(clock, call, arglist) \
-   ((clock) < 0 ? posix_cpu_##call arglist : \
-(*posix_clocks[clock].call) arglist)
-#define DEFHOOK(name)  if (clock->name == NULL) clock->name = common_##name
-#define COMMONDEFN static
-#else
-#define CLOCK_DISPATCH(clock, call, arglist) \
-   ((clock) < 0 ? posix_cpu_##call arglist : \
-(posix_clocks[clock].call != NULL \
- ? (*posix_clocks[clock].call) arglist : common_##call arglist))
-#define DEFHOOK(name)  (void) 0 /* Nothing here.  */
-#define COMMONDEFN static inline
-#endif
+   ((clock) < 0 ? posix_cpu_##call arglist : \
+(posix_clocks[clock].call != NULL \
+ ? (*posix_clocks[clock].call) arglist : common_##call arglist))
 
 /*
  * Default clock hook functions when the struct k_clock passed
@@ -219,25 +200,26 @@ static inline void unlock_timer(struct k
  * the function pointer CALL in struct k_clock.
  */
 
-COMMONDEFN int common_clock_getres(clockid_t which_clock, struct timespec *tp)
+static inline int common_clock_getres(clockid_t which_clock,
+ struct timespec *tp)
 {
tp->tv_sec = 0;
tp->tv_nsec = posix_clocks[which_clock].res;
return 0;
 }
 
-COMMONDEFN int common_clock_get(clockid_t which_clock, struct timespec *tp)
+static inline int common_clock_get(clockid_t which_clock, struct timespec *tp)
 {
getnstimeofday(tp);
return 0;
 }
 
-COMMONDEFN int common_clock_set(clockid_t which_clock, struct timespec *tp)
+static inline int common_clock_set(clockid_t which_clock, struct timespec *tp)
 {
return do_sys_settimeofday(tp, NULL);
 }
 
-COMMONDEFN int common_timer_create(struct k_itimer *new_timer)
+static inline int common_timer_create(struct k_itimer *new_timer)
 {
new_timer->it.real.incr = 0;
init_timer(_timer->it.real.timer);
@@ -258,22 +240,6 @@ static int common_timer_set(struct k_iti
 static int common_timer_del(struct k_itimer *timer);
 
 /*
- * Install default functions for hooks not filled in.
- */
-static inline void common_default_hooks(struct k_clock *clock)
-{
-   DEFHOOK(clock_getres);
-   DEFHOOK(clock_get);
-   DEFHOOK(clock_set);
-   DEFHOOK(timer_create);
-   DEFHOOK(timer_set);
-   DEFHOOK(timer_get);
-   DEFHOOK(timer_del);
-   DEFHOOK(nsleep);
-}
-#undef DEFHOOK
-
-/*
  * Return nonzero iff we know a priori this clockid_t value is bogus.
  */
 static inline int invalid_clockid(clockid_t which_clock)
@@ -589,7 +555,6 @@ void register_posix_clock(clockid_t cloc
}
 
posix_clocks[clock_id] = *new_clock;
-   common_default_hooks(_clocks[clock_id]);
 }
 
 static struct k_itimer * alloc_posix_timer(void)
@@ -997,7 +962,7 @@ static int adjust_abs_time(struct k_cloc
 
 /* Set a POSIX.1b interval timer. */
 /* timr->it_lock is taken. */
-COMMONDEFN int
+static inline int
 common_timer_set(struct k_itimer *timr, int flags,
 struct itimerspec *new_setting, struct itimerspec *old_setting)
 {
@@ -1110,7 +1075,7 @@ retry:
return error;
 }
 
-COMMONDEFN int common_timer_del(struct k_itimer *timer)
+static inline int common_timer_del(struct k_itimer *timer)
 {
timer->it.real.incr = 0;
 #ifdef CONFIG_SMP
-
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-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Bill Rugolsky Jr.]

On Tue, Jan 25, 2005 at 02:03:02PM -0800, Chris Wright wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > did that thread go into technical details? There are some rlimit users
> > that might not be prepared to see the rlimit change under them. The
> > RT_CPU_RATIO one ought to be safe, but generally i'm not so sure.
> 
> Not really.   I mentioned the above, as well as the security concern.
> Right now, at least the task_setrlimit hook would have to change to take
> into account the task.  And I never convinced myself that async changes
> would be safe for each rlimit.

As was mentioned, but not discussed, in the /proc//rlimit thread,
it is not difficult to envision conditions where setrlimit() on another
process could make exploiting an application bug much easier, by, e.g.,
setting number of open files ridiculously low.  So IMHO, it ought require
privileges similar to ptrace() to change some, if not all, of the rlimits.

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

Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

[john stultz]

On Tue, 2005-01-25 at 13:28 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-01-24 at 14:52 -0800, john stultz wrote:
> > All,
> > This patch implements the minimal architecture specific hooks to enable
> > the new time of day subsystem code for i386, x86-64, and ppc64. It
> > applies on top of my linux-2.6.11-rc1_timeofday-core_A2 patch and with
> > this patch applied, you can test the new time of day subsystem. 
> > 
> > Basically it adds the call to timeofday_interrupt_hook() and cuts alot
> > of code out of the build via #ifdefs. I know, I know, #ifdefs' are ugly
> > and bad, and the final patch will just remove the old code. For now this
> > allows us to be flexible and easily switch between the two
> > implementations with a single define. Also it makes the patch a bit
> > easier to read.
> 
> I haven't seen your other patch. Do you mean that with this patch, ppc64
> stops using it's own gettimeofday implementation based on the CPU
> hardware timebase ?

Not quite. It still uses the hardware timebase, but we use a common
infrastructure to calculate time. I believe you'll find the common code
similar to the current ppc64 time code, as it seemed to be one of the
better timeofday implementations (oh the joy of sane hardware time
devices).

> There are reasons why I plan to keep that. First, our implementation is
> very efficient. It allows a timeofday computation without locks or
> barriers thanks to carefully hand crafted data dependencies in the
> operation. 

The performance is a concern, and right now there are issues (ntp_scale
being the top of the list) however I hope they can be resolved. Looking
at ppc64's do_gettimeofday() vs this implementation there we do have
more overhead, but maybe you could suggest how we can avoid some of it?


> Second, we have an ABI issue here. For historical reasons, we
> have this "systemcfg" data structure that can be mmap'ed to userland,
> and which contains copy of some of the ppc64 internal time keeping
> infos. Some userland stuff use it to implement a fully userland
> gettimeofday (again, without barrier nor locks). This is done at least
> by IBM's JVM. My still-to-be-merged vDSO patch will also use this for
> the userland implementation of gettimeofday syscall itself.

I still want to support vsyscall gettimeofday, although it does have to
be done on an arch-by-arch basis. It's likely the systemcfg data
structure can still be generated and exported. I'll look into it and see
what can be done.

thanks
-john


-
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/4] blockable_page_cache_readahead() cleanup

[Steven Pratt]

No problem with this patch either.  Again, not sure it buys much but it 
should work fine.

Steve
Oleg Nesterov wrote:
I think that do_page_cache_readahead() can be inlined
in blockable_page_cache_readahead(), this makes the
code a bit more readable in my opinion.
Also makes check_ra_success() static inline.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 2.6.11-rc2/mm/readahead.c~  2005-01-25 17:26:34.0 +0300
+++ 2.6.11-rc2/mm/readahead.c   2005-01-25 17:29:26.0 +0300
@@ -349,8 +349,8 @@ int force_page_cache_readahead(struct ad
 * readahead isn't helping.
 *
 */
-int check_ra_success(struct file_ra_state *ra, unsigned long nr_to_read,
-unsigned long actual)
+static inline int check_ra_success(struct file_ra_state *ra,
+   unsigned long nr_to_read, unsigned long actual)
{
if (actual == 0) {
ra->cache_hit += nr_to_read;
@@ -395,15 +395,11 @@ blockable_page_cache_readahead(struct ad
{
int actual;
-	if (block) {
-		actual = __do_page_cache_readahead(mapping, filp,
-		offset, nr_to_read);
-	} else {
-		actual = do_page_cache_readahead(mapping, filp,
-		offset, nr_to_read);
-		if (actual == -1)
-			return 0;
-	}
+	if (block && bdi_read_congested(mapping->backing_dev_info))
+		return 0;
+
+	actual = __do_page_cache_readahead(mapping, filp, offset, nr_to_read);
+
	return check_ra_success(ra, nr_to_read, actual);
}
 

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

Drive missing only with LVM kernel

[Jasper Koolhaas]

Hiya,

I run a Linux 2.6.9 kernel with RAID and LVM on a combined total of six
ATA and SATA harddisks. While booting /dev/hdg is recognised and even
used by RAID:

# dmesg |grep hdg
ide3: BM-DMA at 0xdf98-0xdf9f, BIOS settings: hdg:pio, hdh:pio
hdg: WDC WD2000JB-00EVA0, ATA DISK drive
hdg: max request size: 1024KiB
hdg: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63,
UDMA(100)
hdg: cache flushes supported
md:  adding hdg1 ...
md: bind
md: running: 
raid5: device hdg1 operational as raid disk 2
 disk 2, o:1, dev:hdg1

As soon as the system had booted hdg has completely vanished, even in
single user mode:

# ls /dev/hd* /dev/sd*
/dev/hda   /dev/hda3  /dev/hdc1  /dev/hde   /dev/hde3  /dev/sda2  /dev/sdb1
/dev/hda1  /dev/hda4  /dev/hdc2  /dev/hde1  /dev/sda   /dev/sda3  /dev/sdb2
/dev/hda2  /dev/hdc   /dev/hdc3  /dev/hde2  /dev/sda1  /dev/sdb   /dev/sdb3

But the RAID is working just fine:

# cat /proc/mdstat
Personalities : [raid5]
md0 : active raid5 sdb1[4] sda1[3] hdg1[2] hdc1[1] hda1[0]
  97674240 blocks level 5, 256k chunk, algorithm 2 [5/5] [U]

When I boot this same system with the same kernel without LVM appears
just fine. As soon as I compile LVM in (even as not-yet-activated
module) hdg is gone after booting.

This beheavure also happens if I add this particular or a different
drive to a different controller like /dev/hdb

My full kernel config can be found at:
http://www.morgana.net/~jasper/config-2.6.9

Any ideas how I can use LVM and this 6th drive?

hda: 320173056 sectors (163928 MB) w/7936KiB Cache, CHS=19929/255/63,
UDMA(100)
hdc: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)
hde: 398297088 sectors (203928 MB) w/8192KiB Cache, CHS=24792/255/63,
UDMA(100)
hdg: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63,
UDMA(100)
ata1: dev 0 ATA, max UDMA/100, 488397168 sectors: lba48
ata2: dev 0 ATA, max UDMA/100, 488397168 sectors: lba48

Kind regards, Jasper.





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

Re: 2.6.11-rc2-mm1

[Barry K. Nathan]

On Tue, Jan 25, 2005 at 07:12:55PM +, Marcos D. Marado Torres wrote:
> This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still 
> happens.

http://bugme.osdl.org/show_bug.cgi?id=4041

Look at that bug report (especially toward the bottom) for the latest
information.

-Barry K. Nathan <[EMAIL PROTECTED]>

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

Re: [PATCH 4/7] posix-timers: CPU clock support for POSIX timers

[Christoph Lameter]

On Mon, 24 Jan 2005, Christoph Lameter wrote:

> It would be great to have a kind of private field that other clocks (like
> clock drivers) could use for their purposes. mmtimer f.e. does use some
> of the fields for the tick based timers for its purposes.

On that note:

Your patch breaks the mmtimer driver because it used k_itimer values for
its own purposes. Here is a fix by defining an additional structure
in k_itimer (same approach for mmtimer as the cpu timers):

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

Index: linux-2.6.10/include/linux/posix-timers.h
===
--- linux-2.6.10.orig/include/linux/posix-timers.h  2005-01-25 
14:35:11.0 -0800
+++ linux-2.6.10/include/linux/posix-timers.h   2005-01-25 14:35:16.0 
-0800
@@ -57,6 +57,12 @@ struct k_itimer {
unsigned long incr; /* interval in jiffies */
} real;
struct cpu_timer_list cpu;
+   struct {
+   unsigned int clock;
+   unsigned int node;
+   unsigned long incr;
+   unsigned long expires;
+   } mmtimer;
} it;
 };

Index: linux-2.6.10/drivers/char/mmtimer.c
===
--- linux-2.6.10.orig/drivers/char/mmtimer.c2005-01-25 14:35:09.0 
-0800
+++ linux-2.6.10/drivers/char/mmtimer.c 2005-01-25 14:34:41.0 -0800
@@ -420,19 +420,19 @@ static int inline reschedule_periodic_ti
int n;
struct k_itimer *t = x->timer;

-   t->it_timer.magic = x->i;
+   t->it.mmtimer.clock = x->i;
t->it_overrun--;

n = 0;
do {

-   t->it_timer.expires += t->it_incr << n;
+   t->it.mmtimer.expires += t->it.mmtimer.incr << n;
t->it_overrun += 1 << n;
n++;
if (n > 20)
return 1;

-   } while (mmtimer_setup(x->i, t->it_timer.expires));
+   } while (mmtimer_setup(x->i, t->it.mmtimer.expires));

return 0;
 }
@@ -468,7 +468,7 @@ mmtimer_interrupt(int irq, void *dev_id,
spin_lock([i].lock);
if (base[i].cpu == smp_processor_id()) {
if (base[i].timer)
-   expires = base[i].timer->it_timer.expires;
+   expires = base[i].timer->it.mmtimer.expires;
/* expires test won't work with shared irqs */
if ((mmtimer_int_pending(i) > 0) ||
(expires && (expires < rtc_time( {
@@ -505,7 +505,7 @@ void mmtimer_tasklet(unsigned long data)

t->it_overrun++;
}
-   if(t->it_incr) {
+   if(t->it.mmtimer.incr) {
/* Periodic timer */
if (reschedule_periodic_timer(x)) {
printk(KERN_WARNING "mmtimer: unable to reschedule\n");
@@ -513,7 +513,7 @@ void mmtimer_tasklet(unsigned long data)
}
} else {
/* Ensure we don't false trigger in mmtimer_interrupt */
-   t->it_timer.expires = 0;
+   t->it.mmtimer.expires = 0;
}
t->it_overrun_last = t->it_overrun;
 out:
@@ -524,7 +524,7 @@ out:
 static int sgi_timer_create(struct k_itimer *timer)
 {
/* Insure that a newly created timer is off */
-   timer->it_timer.magic = TIMER_OFF;
+   timer->it.mmtimer.clock = TIMER_OFF;
return 0;
 }

@@ -535,8 +535,8 @@ static int sgi_timer_create(struct k_iti
  */
 static int sgi_timer_del(struct k_itimer *timr)
 {
-   int i = timr->it_timer.magic;
-   cnodeid_t nodeid = timr->it_timer.data;
+   int i = timr->it.mmtimer.clock;
+   cnodeid_t nodeid = timr->it.mmtimer.node;
mmtimer_t *t = timers + nodeid * NUM_COMPARATORS +i;
unsigned long irqflags;

@@ -544,8 +544,8 @@ static int sgi_timer_del(struct k_itimer
spin_lock_irqsave(>lock, irqflags);
mmtimer_disable_int(cnodeid_to_nasid(nodeid),i);
t->timer = NULL;
-   timr->it_timer.magic = TIMER_OFF;
-   timr->it_timer.expires = 0;
+   timr->it.mmtimer.clock = TIMER_OFF;
+   timr->it.mmtimer.expires = 0;
spin_unlock_irqrestore(>lock, irqflags);
}
return 0;
@@ -558,7 +558,7 @@ static int sgi_timer_del(struct k_itimer
 static void sgi_timer_get(struct k_itimer *timr, struct itimerspec 
*cur_setting)
 {

-   if (timr->it_timer.magic == TIMER_OFF) {
+   if (timr->it.mmtimer.clock == TIMER_OFF) {
cur_setting->it_interval.tv_nsec = 0;
cur_setting->it_interval.tv_sec = 0;
cur_setting->it_value.tv_nsec = 0;
@@ -566,8 +566,8 @@ static void sgi_timer_get(struct k_itime
return;
}

-   

Re: [PATCH] Use MM_VM_SIZE in exit_mmap

[Ian Molton]

Anton Blanchard wrote:
> As an aside, all architectures except one define FIRST_USER_PGD_NR as 0:
>
> include/asm-arm26/pgtable.h:#define FIRST_USER_PGD_NR   1
All processes on arm26 must map the same page 0 as its where the SWI 
vector table goes. The vector table is located at address 0, and as such 
becomes virtual address space once the MMU is switched on. This is 
unavoidable, unlike later ARMs which can remap it elsewhere.

The only way this could work is if you do the zeroing with all 
interrupts off and restore page 0 afterwards, which seems rather silly 
to 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: [Fwd: TASK_SIZE is variable.]

[David Woodhouse]

On Tue, 2005-01-25 at 22:46 +, Christoph Hellwig wrote:
> > Bad things can happen if a 32-bit process is the last user of a 64-bit
> > mm. TASK_SIZE isn't a constant, and we can end up clearing page tables
> > only up to the 32-bit TASK_SIZE instead of all the way. We should
> > probably double-check every instance of TASK_SIZE or USER_PTRS_PER_PGD
> > for this kind of problem.
> 
> Or better get rid of TASK_SIZE completely.  Having something that looks
> like a constant change depending on the user process is a bad idea.

Yeah, that's possibly a sane plan.

-- 
dwmw2


-
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: PANIC in check_process_timers() running 2.6.11-rc2-mm1

[Alexander Nyberg]

> Thanks for tracking that down.  It was intended that such things would not
> be possible because getting into that code in the first place should be
> ruled out while exiting.  That removes the requirement for any special case
> check in the common path.  But, it was done too late since it hadn't
> occurred to me that ->live going zero itself created a problem.
> 
> Please try this patch instead of the one you posted.  This patch goes on
> top of all the patches I posted, and so should apply to -mm1 fine.  But
> because the context nearby changes a lot in the various patches, this one
> won't apply after just the cputimers patch without the succeeding three.

Yep, appears to be working fine here and cleaner :-)

-
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 3/4] cleanup ahead window calculation

[Steven Pratt]

Not sure how much better this is, but it doesn't hurt anything.
Steve
Oleg Nesterov wrote:
This patch moves some code into the get_next_ra_size()
and renames it into 'set_next_ahead_window'.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 2.6.11-rc2/mm/readahead.c~  2005-01-25 15:17:13.0 +0300
+++ 2.6.11-rc2/mm/readahead.c   2005-01-25 16:51:50.0 +0300
@@ -85,20 +85,23 @@ static unsigned long get_init_ra_size(un
 * not for each call to readahead.  If a cache miss occured, reduce next I/O
 * size, else increase depending on how close to max we are.
 */
-static unsigned long get_next_ra_size(unsigned long cur, unsigned long max,
-   unsigned long min, unsigned long * flags)
+static void set_next_ahead_window(struct file_ra_state *ra,
+   unsigned long max, unsigned long min)
{
unsigned long newsize;
+   unsigned long cur = ra->size;
-   if (*flags & RA_FLAG_MISS) {
+   ra->ahead_start = ra->start + cur;
+
+   if (ra->flags & RA_FLAG_MISS) {
+   ra->flags &= ~RA_FLAG_MISS;
newsize = max((cur - 2), min);
-   *flags &= ~RA_FLAG_MISS;
-   } else if (cur < max / 16) {
+   } else if (cur < max / 16)
newsize = 4 * cur;
-   } else {
+   else
newsize = 2 * cur;
-   }
-   return min(newsize, max);
+
+   ra->ahead_size = min(newsize, max);
}
#define list_to_page(head) (list_entry((head)->prev, struct page, lru))
@@ -457,9 +460,7 @@ page_cache_readahead(struct address_spac
 * immediately.
 */
if (req_size >= max) {
-   ra->ahead_size = get_next_ra_size(ra->size, max, min,
- >flags);
-   ra->ahead_start = ra->start + ra->size;
+   set_next_ahead_window(ra, max, min);
blockable_page_cache_readahead(mapping, filp,
 ra->ahead_start, ra->ahead_size, ra, 1);
}
@@ -497,9 +498,7 @@ page_cache_readahead(struct address_spac
ra->size = ra->ahead_size;
}
-   ra->ahead_size = get_next_ra_size(ra->size, max, min,
-   >flags);
-   ra->ahead_start = ra->start + ra->size;
+   set_next_ahead_window(ra, max, min);
		block = ((offset + newsize - 1) >= ra->ahead_start);
		if (!blockable_page_cache_readahead(mapping, filp,
 

-
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] kernel/configs.c: make a variable static

[Randy.Dunlap]

Adrian Bunk wrote:
This patch makes a needlessly global variable static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 12 Dec 2004
--- linux-2.6.10-rc2-mm4-full/kernel/Makefile.old	2004-12-12 02:45:07.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/Makefile	2004-12-12 02:45:18.0 +0100
@@ -48,7 +48,7 @@
 	$(call if_changed,gzip)
 
 quiet_cmd_ikconfiggz = IKCFG   $@
-  cmd_ikconfiggz = (echo "const char kernel_config_data[] = MAGIC_START"; cat $< | scripts/bin2c; echo "MAGIC_END;") > $@
+  cmd_ikconfiggz = (echo "static const char kernel_config_data[] = MAGIC_START"; cat $< | scripts/bin2c; echo "MAGIC_END;") > $@
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
 	$(call if_changed,ikconfiggz)

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