RE: Giving developers clue how many testers verifiedcertain kernel version

[Al Boldi]

Lee Revell wrote: {
On Fri, 2005-07-22 at 21:15 -0500, Alejandro Bonilla wrote:
> OK, I will, but I first of all need to learn how to tell if benchmarks 
> are better or worse.

Con's interactivity benchmark looks quite promising for finding scheduler
related interactivity regressions.
}

Scheduler performance does not imply net system performance.

In fact, a well tuned scheduler hides absolute performance-related issues!

--Al


-
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: kernel optimization

[Al Boldi]

 Adrian Bunk wrote: {
On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:
> i would like to ask if it possible to change the optimization of the 
> kernel from -O2 to -O3 :D, how can i do that? if i change it to the 
> top level Makefile does it change to all the Makefiles?
And since it's larger, it's also slower.
}

It's faster but it's flawed.  Root-NFS boot failed!

-
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: Kernel doesn't free Cached Memory

[Al Boldi]

Dick Johnson wrote: { 
> On Fri, 2005-07-22 at 08:27 -0300, Vinicius wrote:
> [...]
>>I have a server with 2 Pentium 4 HT processors and 32 GB of RAM, 
>> this server runs lots of applications that consume lots of memory to. 
>> When I stop this applications, the kernel doesn't free memory (the  
>> memory still in use) and the server cache lots of memory (~27GB). 
>> When I start this applications, the kernel sends  "Out of Memory" 
>> messages and kill some random applications.

...you might even need to turn memory over-commit off:
  echo "0" > /proc/sys/vm/overcommit_memory
}

That's in 2.4. In 2.6 it's:
  echo "2" > /proc/sys/vm/overcommit_memory

But the kernel doesn't honor no-overcommit in either version, i.e. it still
overcommits/pages-out loaded/running procs, thus invoking OOM!

Is there a way to make the kernel strictly honor the no-overcommit request?

Thanks!

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

Re: sys_times() return value

[Andrew Morton]

Russell King <[EMAIL PROTECTED]> wrote:
>
> Guys,
> 
> ARM folk have recently pointed out a problem with sys_times().
> When the kernel boots, we set jiffies to -5 minutes.  This causes
> sys_times() to return a negative number, which increments through
> zero.
> 
> However, some negative numbers are used to return error codes.
> Hence, there's a period of time when sys_times() returns values
> which are indistinguishable from error codes shortly after boot.

What a strange system call.

> This probably only affects 32-bit architectures.  However, one
> wonders whether sys_times() needs force_successful_syscall_return().

I'd say so, yes.  But lots of architectures seem to have a no-op there.

> Also, it appears that glibc does indeed interpret the return value
> from sys_times in the way I describe above on at least ARM and x86.
> Other architectures may be similarly affected.  Hopefully the ARM
> glibc folk will raise a cross-architecture bug in glibc for this.
> 

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

[GIT PATCH] ACPI for 2.6

[Brown, Len]

Hi Linus,

Please pull from: 

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/linux-2.6.git/

for a single patch that removes some recently added
debugging console messages.

thanks!

-Len

 ec.c |   17 +++--
 1 files changed, 3 insertions(+), 14 deletions(-)


commit 668d74c04c16bb69de564e25e85dd94eeb0175d9
Author: Luming Yu <[EMAIL PROTECTED]>
Date:   Sat Jul 23 00:26:33 2005 -0400

ACPI: delete unnecessary EC console messages

http://bugzilla.kernel.org/show_bug.cgi?id=4534

Signed-off-by: Luming Yu <[EMAIL PROTECTED]>
Signed-off-by: Len Brown <[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/

[no subject]

[Mr.Derrick Tanner.]

-
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: Failure to deliver SIGCHLD

[Edgar Toernig]

Michael Harris wrote:
>
> [2.] The problem occurs in a forking server similar in function to
> inetd.  The server employs a very simple SIGCHLD handler that loops on
> wait(2), until all zombie processes have been collected.  For no
> immediately apparent reason, the parent process behaves as if it no
> longer receives SIGCHLD.  Manually sending the signal has no effect.

Sounds like a blocked signal.

> [6.] This is the code for the signal handler in the server application. 
> 
> void reaper_man (int signum)
> {
> int stat;
> while ( waitpid(-1, , WNOHANG) > 0 );
> }
> 
> signal (SIGCHLD, reaper_man);  /* from main() */
>
> I dare say it contains no bugs (famous last words)

It does - it clobbers errno :-)

My suggestions: use sigaction with defined restart/mask/etc behaviour
instead of signal.  Save and restore errno in the signal handler.
Make sure SIGCHLD isn't blocked.

But if your only interest is to get rid of the zombies, the most simple
solution would be to set SIGCHLD to ignore.

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

Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)

[Matthew Helsley]

On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote:
> > > actually, let me also say that CKRM is on a continuum that includes 
> > > current (global) /proc tuning for various subsystems, ulimits, and 
> > > at the other end, Xen/VMM's.  it's conceivable that CKRM could wind up
> > > being useful and fast enough to subsume the current global and per-proc
> > > tunables.  after all, there are MANY places where the kernel tries to 
> > > maintain some sort of context to allow it to tune/throttle/readahead
> > > based on some process-linked context.  "embracing and extending"
> > > those could make CKRM attractive to people outside the mainframe market.
> > 
> > Seems like an excellent suggestion to me! Yeah, it may be possible to
> > maintain the context the kernel keeps on a per-class basis instead of
> > globally or per-process. 
> 
> right, but are the CKRM people ready to take this on?  for instance,
> I just grepped 'throttle' in kernel/mm and found a per-task RM in 
> page-writeback.c.  it even has a vaguely class-oriented logic, since
> it exempts RT tasks.  if CKRM can become a way to make this stuff 
> cleaner and more effective (again, for normal tasks), then great.
> but bolting on a big new different, intrusive mechanism that slows
> down all normal jobs by 3% just so someone can run 10K mostly-idle
> guests on a giant Power box, well, that's gross.
> 
> > The real question is what constitutes a useful
> > "extension" :).
> 
> if CKRM is just extensions, I think it should be an external patch.
> if it provides a path towards unifying the many disparate RM mechanisms
> already in the kernel, great!

OK, so if it provides a path towards unifying these, what should happen
to the old interfaces when they conflict with those offered by CKRM?

For instance, I'm considering how a per-class (re)nice setting would
work. What should happen when the user (re)nices a process to a
different value than the nice of the process' class? Should CKRM:

a) disable the old interface by
i) removing it
ii) return an error when CKRM is active
iii) return an error when CKRM has specified a nice value for the
process via membership in a class
iv) return an error when the (re)nice value is inconsistent with the
nice value assigned to the class

b) trust the user, ignore the class nice value, and allow the new nice
value

I'd be tempted to do a.iv but it would require some modifications to a
system call. b probably wouldn't require any modifications to non-CKRM
files/dirs. 

This sort of question would probably come up for any other CKRM
"embraced-and-extended" tunables. Should they use the answer to this
one, or would it go on a case-by-case basis?

Thanks,
-Matt Helsley

-
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: Giving developers clue how many testers verified certain kernel version

[Adrian Bunk]

On Fri, Jul 22, 2005 at 09:15:14PM -0500, Alejandro Bonilla wrote:
> Lee Revell wrote:
> 
> >On Fri, 2005-07-22 at 20:07 -0500, Alejandro Bonilla wrote:
> > 
> >>I will get flames for this, but my laptop boots faster and sometimes 
> >>responds faster in 2.4.27 than in 2.6.12. Sorry, but this is the fact 
> >>for me. IBM T42.
> >
> >Sorry dude, but there's just no way that any automated process can catch
> >these.
> >
> I'm not looking for an automated process for this. But for all in 
> general, when moving from 2.6.11 to 2.6.12 or from any version to 
> another. (At least in the same kernel branch)
>...

You send:
- a problem description X
- tell that the last working kernel was Y
- tell that it is broken in kernel Z

The probability of any kernel developer being interested in your problem 
increases:
- the better the description X is
- the nearer versions Y and Z are together
- the more recent version Y is

Ideally, you are able to say that patch A in the latest -mm kernel
broke it.

It's perfectly OK to send a description X that says:
- with version Y and the following workload B, everything is working
  perfectly
- with version Z and the same workload B, XMMS is stuttering

If any kernel developer is interested in your bug report, he will tell 
you which data might be interesting for debugging the problem.

The problem is that debugging a problem often requires knowledge about 
possible causes and changes between versions Y and Z in this area. Even 
a kernel developer who perfectly knows one part of the kernel might not 
be able to debug a problem in a completely different area of the kernel.

> .Alejandro

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 2/2] Touchscreen support for sharp sl-5500

[Dmitry Torokhov]

On Friday 22 July 2005 19:28, Pavel Machek wrote:
> This adds support for touchscreen on Sharp Zaurus sl-5500. Vojtech,
> please apply,

I have couple more commnets...

> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
> + allow_signal(SIGKILL);

This is not needed...

> +
> + /*
> +  * We run as a real-time thread.  However, thus far
> +  * this doesn't seem to be necessary.
> +  */
> + tsk->policy = SCHED_FIFO;
> + tsk->rt_priority = 1;
> +
> + complete(>init_exit);
> +

Neither this one - kthread_create does not return until thread is actually
created and started.

> +
> + if (signal_pending(tsk))
> + break;

if (kthread_should_stop(..))
break;

> + }
> +
> + ts->rtask = NULL;
> + complete_and_exit(>init_exit, 0);

This is not needed.

> +static int ucb1x00_ts_open(struct input_dev *idev)
> +{
> + struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
> + int ret = 0;
> + struct task_struct *task;
> +
> + if (ts->rtask)
> + panic("ucb1x00: rtask running?");
> +

Do you really need to panic here???

> +
> + init_completion(>init_exit);
> + task = kthread_run(ucb1x00_thread, ts, "ktsd");
> + if (!IS_ERR(task)) {
> + wait_for_completion(>init_exit);

Just call kthread_run() and kill that init_exit completion. 

> +static void ucb1x00_ts_close(struct input_dev *idev)
> +{
> + struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
> +
> + if (ts->rtask) {
> + send_sig(SIGKILL, ts->rtask, 1);
> + wait_for_completion(>init_exit);

kthread_stop().

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

Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[Harald Welte]

On Fri, Jul 22, 2005 at 11:05:59PM -0400, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Sat, 23 Jul 2005 08:54:27 -0400), Harald 
> Welte <[EMAIL PROTECTED]> says:
> 
> > --- a/include/linux/netlink.h
> > +++ b/include/linux/netlink.h
> > @@ -20,7 +20,7 @@
> >  #define NETLINK_IP6_FW 13
> >  #define NETLINK_DNRTMSG14  /* DECnet routing messages */
> >  #define NETLINK_KOBJECT_UEVENT 15  /* Kernel messages to userspace 
> > */
> > -#define NETLINK_TAPBASE16  /* 16 to 31 are ethertap */
> > +#define NETLINK_W1 16  /* 16 to 31 are ethertap */
> >  
> >  #define MAX_LINKS 32   
> >  
> 
> Comment says that 16-31 are used for ethertap.
> So, probably assigh NETLINK_W1 at 32, and bump MAX_LINKS?

MAX_LINKS > 32 would result in larger statically allocated pointer
arrays.  It would also only work if NPROTO is increased too, IIRC.

I strongly disrecommend increasing NPROTO.  Maybe we should look into
reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).

But to be honest, I don't really care all that much as long as existing
and still very actively used values are not just overloaded.

-- 
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/

  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."-- Paul Vixie


pgpTs1HzWp2SU.pgp
Description: PGP signature

Re: Giving developers clue how many testers verified certain kernel version

[Alejandro Bonilla]

Linus Torvalds wrote:


On Fri, 22 Jul 2005, Lee Revell wrote:
 


Con's interactivity benchmark looks quite promising for finding
scheduler related interactivity regressions.
   



I doubt that _any_ of the regressions that are user-visible are
scheduler-related. They all tend to be disk IO issues (bad scheduling or
just plain bad drivers), and then sometimes just VM misbehaviour.

People are looking at all these RT patches, when the thing is that most
nobody will ever be able to tell the difference between 10us and 1ms
latencies unless it causes a skip in audio.
 

True, and I just couldn't agree more with Lee that lots of the delays 
that one looks at is because of user space. Still, I have some doubt on 
how faster 2.6 is sometimes, where 2.4 is faster in other things.


i.e. As my newbie view, I can see 2.6 running faster in X, Compiling and 
stuff, but I see 2.4 working much faster when running commands, response 
and interaction in the console. But then again, this could be only me...




Linus

 


.Alejandro
-
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: Giving developers clue how many testers verified certain kernel version

[Alejandro Bonilla]

Lee Revell wrote:


On Fri, 2005-07-22 at 21:15 -0500, Alejandro Bonilla wrote:
 

OK, I will, but I first of all need to learn how to tell if benchmarks 
are better or worse.
   



Con's interactivity benchmark looks quite promising for finding
scheduler related interactivity regressions.  It certainly has confirmed
what we already knew re: SCHED_FIFO performance, if we extend that to
SCHED_OTHER which is a more interesting problem then there's serious
potential for improvement.  AFAIK no one has posted any 2.4 vs 2.6
interbench results yet...
 


I will give it a try.


I suspect a lot of the boot time issue is due to userspace.  But, it
should be trivial to benchmark this one, just use the TSC or whatever to
measure the time from first kernel entry to execing init().
 

You got it! As a laptop user, I think it just takes too much more. I 
think it is maybe hotplugs fault with the kernel? I don't know how much 
is done by the kernel or userspace but it definitely takes longer.


I could do some sort of benchmarks, but believe me, I hate to say this, 
but I use 2.6 because of much more power managements features in it. 
Else I like 2.4 a lot more. Is like, the feels is sharper. Sometimes 
when I got into a tty1, it takes some time after I put my username in to 
prompt me for a password. This does not occur when I boot with 2.4.27. 
Strange huh?


I don't want to be an ass and say that 2.4 is better, instead I want to 
help and let determine why is it that I feel 2.6 slower.


.Alejandro

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/

Re: Giving developers clue how many testers verified certain kernel version

[Lee Revell]

On Fri, 2005-07-22 at 20:31 -0700, Linus Torvalds wrote:
> 
> On Fri, 22 Jul 2005, Lee Revell wrote:
> > 
> > Con's interactivity benchmark looks quite promising for finding
> > scheduler related interactivity regressions.
> 
> I doubt that _any_ of the regressions that are user-visible are
> scheduler-related. They all tend to be disk IO issues (bad scheduling or
> just plain bad drivers), and then sometimes just VM misbehaviour.
> 
> People are looking at all these RT patches, when the thing is that most
> nobody will ever be able to tell the difference between 10us and 1ms
> latencies unless it causes a skip in audio.

I agree re: the RT patches, but what makes Con's benchmark useful is
that it also tests interactivity (measuring in msecs vs. usecs) with
everything running SCHED_NORMAL, which is a much better approximation of
a desktop load.  And the numbers do go well up into the range where
people would notice, tens and hundreds of ms.

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/

Re: [QN/PATCH] Why do some archs allocate stack via kmalloc, others via get_free_pages?

[Nigel Cunningham]

Hi.

On Fri, 2005-07-22 at 17:50, David S. Miller wrote:
> From: Nigel Cunningham <[EMAIL PROTECTED]>
> Date: Fri, 22 Jul 2005 14:11:17 +1000
> 
> > In making some modifications to Suspend, we've discovered that some
> > arches use kmalloc and others use get_free_pages to allocate the stack.
> > Is there a reason for the variation? If not, could the following patch
> > be considered for inclusion (tested on x86 only).
> 
> Some platforms really need it to be page aligned (sparc32 sun4c needs
> to virtually map the resulting pages into a specific place, for
> example).
> 
> But, for the ones that don't have this requirement, they want the
> cache coloring.

Thanks David.

Nigel

-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-
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: Giving developers clue how many testers verified certain kernel version

[Lee Revell]

On Fri, 2005-07-22 at 21:15 -0500, Alejandro Bonilla wrote:
> OK, I will, but I first of all need to learn how to tell if benchmarks 
> are better or worse.

Con's interactivity benchmark looks quite promising for finding
scheduler related interactivity regressions.  It certainly has confirmed
what we already knew re: SCHED_FIFO performance, if we extend that to
SCHED_OTHER which is a more interesting problem then there's serious
potential for improvement.  AFAIK no one has posted any 2.4 vs 2.6
interbench results yet...

I suspect a lot of the boot time issue is due to userspace.  But, it
should be trivial to benchmark this one, just use the TSC or whatever to
measure the time from first kernel entry to execing init().

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/

Re: Giving developers clue how many testers verified certain kernel version

[Alejandro Bonilla]

Lee Revell wrote:


On Fri, 2005-07-22 at 20:07 -0500, Alejandro Bonilla wrote:
 

I will get flames for this, but my laptop boots faster and sometimes 
responds faster in 2.4.27 than in 2.6.12. Sorry, but this is the fact 
for me. IBM T42.
   



Sorry dude, but there's just no way that any automated process can catch
these.
 

I'm not looking for an automated process for this. But for all in 
general, when moving from 2.6.11 to 2.6.12 or from any version to 
another. (At least in the same kernel branch)



You will have to provide a detailed bug report (with numbers) like
everyone else so we can fix it.  "Waiting for it to fix itself" is the
WORST thing you can do.
 

I never do this, believe me, but I could if I don't really see a 
problem. But there could really be one behind.



If you find a regression vs. an earlier kernel, please assume that
you're the ONLY one to notice it and respond accordingly.
 

OK, I will, but I first of all need to learn how to tell if benchmarks 
are better or worse.



Lee

 


.Alejandro
-
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: Giving developers clue how many testers verified certain kernel version

[Lee Revell]

On Fri, 2005-07-22 at 20:07 -0500, Alejandro Bonilla wrote:
> I will get flames for this, but my laptop boots faster and sometimes 
> responds faster in 2.4.27 than in 2.6.12. Sorry, but this is the fact 
> for me. IBM T42.

Sorry dude, but there's just no way that any automated process can catch
these.

You will have to provide a detailed bug report (with numbers) like
everyone else so we can fix it.  "Waiting for it to fix itself" is the
WORST thing you can do.

If you find a regression vs. an earlier kernel, please assume that
you're the ONLY one to notice it and respond accordingly.

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/

Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[YOSHIFUJI Hideaki / 吉藤英明]

In article <[EMAIL PROTECTED]> (at Sat, 23 Jul 2005 08:54:27 -0400), Harald 
Welte <[EMAIL PROTECTED]> says:

> --- a/include/linux/netlink.h
> +++ b/include/linux/netlink.h
> @@ -20,7 +20,7 @@
>  #define NETLINK_IP6_FW   13
>  #define NETLINK_DNRTMSG  14  /* DECnet routing messages */
>  #define NETLINK_KOBJECT_UEVENT   15  /* Kernel messages to userspace 
> */
> -#define NETLINK_TAPBASE  16  /* 16 to 31 are ethertap */
> +#define NETLINK_W1   16  /* 16 to 31 are ethertap */
>  
>  #define MAX_LINKS 32 
>  

Comment says that 16-31 are used for ethertap.
So, probably assigh NETLINK_W1 at 32, and bump MAX_LINKS?

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

[PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

[Harald Welte]

Hi Dave,
Hi Evgeniy,

the following patch fixes the illegal use of NETLINK_NFLOG by the
1wire drivers.  It assumes that the netlink tap families can now safely
be reclaimed, which is the case according to Dave at netconf'05.

I'm not sure who would be the right person to fix this, but this patch
needs to go into both 2.6.12.x and 2.6.13 trees, since it potentially
causes a security problem by preventing the iptables ULOG

This has been the third new piece of code that reuses NETLINK_NFLOG
within a couple of months.  I would really appreciate if people would
actually ask/apply for a new protocol number instead of just overloading
existing values and thereby causing breakage.  

Thanks,
Harald

-- 
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/

  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."-- Paul Vixie
Give the 1-wire driver stack its own netlink protocol number, instead of
overloading NETLINK_NFLOG.

I wonder what I have done to people, that they always overload the
NETLINK_NFLOG protocol number and thereby effectively prevent the packet
filter logging mechanism.  Please don't re-use protocol numbers.

Signed-off-by: Harald Welte <[EMAIL PROTECTED]>

---
commit b4a566c332048b642506eff7de825fce710ff42c
tree 07ef162f6d449dd67c586c9c63680004787b86c5
parent d5d3fb40b6db511dbd47a84634a1249de6b7b297
author laforge <[EMAIL PROTECTED]> Sa, 23 Jul 2005 08:41:24 -0400
committer laforge <[EMAIL PROTECTED]> Sa, 23 Jul 2005 08:41:24 -0400

 drivers/w1/w1_int.c |4 ++--
 include/linux/netlink.h |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -88,10 +88,10 @@ static struct w1_master * w1_alloc_dev(u
 
dev->groups = 23;
dev->seq = 1;
-   dev->nls = netlink_kernel_create(NETLINK_NFLOG, NULL);
+   dev->nls = netlink_kernel_create(NETLINK_W1, NULL);
if (!dev->nls) {
printk(KERN_ERR "Failed to create new netlink socket(%u) for w1 
master %s.\n",
-   NETLINK_NFLOG, dev->dev.bus_id);
+   NETLINK_W1, dev->dev.bus_id);
}
 
err = device_register(>dev);
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -20,7 +20,7 @@
 #define NETLINK_IP6_FW 13
 #define NETLINK_DNRTMSG14  /* DECnet routing messages */
 #define NETLINK_KOBJECT_UEVENT 15  /* Kernel messages to userspace */
-#define NETLINK_TAPBASE16  /* 16 to 31 are ethertap */
+#define NETLINK_W1 16  /* 16 to 31 are ethertap */
 
 #define MAX_LINKS 32   
 


pgpMMbFchIvsE.pgp
Description: PGP signature

Re: HPT370 errors under 2.6.13-rc3-mm1

[Bartlomiej Zolnierkiewicz]

Hi,

Does vanilla kernel 2.6.12 work for you?
It doesn't contain hpt366 driver update.

Bartlomiej

On 7/22/05, mdew <[EMAIL PROTECTED]> wrote:
> I'm unable to mount an ext2 drive using the hpt370A raid card.
> 
> upon mounting the drive, dmesg will spew these errors..I've tried
> different cables and drive is fine.
> 
> Jul 23 01:30:11 localhost kernel: hdf: dma_timer_expiry: dma status == 0x41
> Jul 23 01:30:21 localhost kernel: hdf: DMA timeout error
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: status=0x25
> { DeviceFault CorrectedError Error }
> Jul 23 01:30:21 localhost kernel: hdf: dma timeout error: error=0x25 {
> DriveStatusError AddrMarkNotFound }, LBAsect=8830589412645,
> high=526344, low=2434341, sector=390715711
> Jul 23 01:30:21 localhost kernel: ide: failed opcode was: unknown
> Jul 23 01:30:21 localhost kernel: hdf: DMA disabled
> Jul 23 01:30:21 localhost kernel: ide2: reset: master: error (0x0a?)
> Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> sector 390715711
> Jul 23 01:30:21 localhost kernel: end_request: I/O error, dev hdf,
> sector 390715712
> [...]
-
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: Merging relayfs?

[Tom Zanussi]

Karim Yaghmour writes:
 > 
 > Tom Zanussi wrote:
 > > - removed the deliver() callback
 > > - removed the relay_commit() function
 > 
 > This breaks LTT. Any reason why this needed to be removed? In the end,
 > the code will just end up being duplicated in ltt and all other users.
 > IOW, this is not some potential future use, but something that's
 > currently being used.

Because I realized that like the padding and commit arrays, they're
not really necessary.

In all the examples, the padding is saved in space reserved at the
beginning of the sub-buffer via subbuf_start_reserve(), except that
now the padding is passed into the subbuf_start() callback rather than
kept in an array.  The padding value passed in is then directly saved
in the reserved padding space.

Similarly, in the case of the reserve/commit example, extra space is
also reserved for the commit count using subbuf_start_reserve().
After space for an event is reserved using relay_reserve() and
completely written, the event length is added to that commit value.
In userspace, the sub-buffer reading loop looks at the commit value in
the sub-buffer, and if it matches (sub-buffer size - padding), the
buffer has been completely written and can be saved, otherwise it's
not yet complete and is checked again the next time around.  This way,
there's no need for a deliver() callback, the relay_commit() is
replaced with the increment of the reserved commit value, the arrays
aren't needed and you get the same result in the end in a much simpler
way, IMHO.

But if you see a problem with it or have any suggestions to make it
better/different, please let me know...

Tom


-
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: [UPDATE PATCH] Add schedule_timeout_{interruptible,uninterruptible}_msecs() interfaces

[Andrew Morton]

Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
>
> 
> +/*
> + * schedule_timeout_msecs - sleep until timeout
> + * @timeout_msecs: timeout value in milliseconds
> + *
> + * A human-time (but otherwise identical) alternative to
> + * schedule_timeout() The state, therefore, *does* need to be set before
> + * calling this function, but this function should *never* be called
> + * directly. Use the nice wrappers, schedule_{interruptible,
> + * uninterruptible}_timeout_msecs().
> + *
> + * See the comment for schedule_timeout() for details.
> + */
> +inline unsigned int __sched schedule_timeout_msecs(unsigned int 
> timeout_msecs)
> +{

Making this inline will add more kernel text.Can't we uninline it?

I'm surprised that this function is not implemented as a call to the
existing schedule_timeout()?

> + init_timer();
> + timer.expires = expire_jifs;
> + timer.data = (unsigned long) current;
> + timer.function = process_timeout;

hm, if we add the needed typecast to TIMER_INITIALIZER() the above could be

timer = TIMER_INITIALIZER(process_timeout, expire_jifs,
(unsigned long)current);


-
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: Giving developers clue how many testers verified certain kernel version

[Alejandro Bonilla]

Blaisorblade wrote:


Adrian Bunk  stusta.de> writes:
 


On Thu, Jul 21, 2005 at 09:40:43PM -0500, Alejandro Bonilla wrote:
   

  How do we know that something is OK or wrong? just by the fact that 
it works or not, it doesn't mean like is OK.


There has to be a process for any user to be able to verify and study a 
problem. We don't have that yet.
 



 

If the user doesn't notice the difference then there's no problem for 
him.
   

Some performance regressions aren't easily noticeable without benchmarks... 
and we've had people claiming unnoticed regressions since 2.6.2 
(http://kerneltrap.org/node/4940)
 

I will get flames for this, but my laptop boots faster and sometimes 
responds faster in 2.4.27 than in 2.6.12. Sorry, but this is the fact 
for me. IBM T42.


If there's a problem the user notices, then the process is to send an 
email to linux-kernel and/or open a bug in the kernel Bugzilla and 
follow the "please send the output of foo" and "please test patch bar" 
instructions.
   

The thing is, I might not be able to know there *are* issues. I most 
just notice that something is strange. And then wait for a new kernel 
version because i might think it is something silly.




 

What comes nearest to what you are talking about is that you run LTP 
and/or various benchmarks against every -git and every -mm kernel and 
report regressions. But this is sinply a task someone could do (and I 
don't know how much of it is already done e.g. at OSDL), and not 
something every user could contribute to.
   



Forgot drivers testing? That is where most of the bugs are hidden, and where 
wide user testing is definitely needed because of the various hardware bugs 
and different configurations existing in real world.
 

This is my opinion too. If someone could do a simple script or 
benchmarking file, then users would be able to report most common 
important differences from previous kernel versions on their systems.


i.e. i would run the script that checks the write speed, CPU, latencys, 
and I don't know how many more tests and then compare it with the 
results that were with the previous git or full kernel release. 
Sometimes the users don't even know the commands to benchmark this parts 
of the systems. I don't know them.


IMHO, I think that publishing statistics about kernel patches downloads would 
be a very Good Thing(tm) to do. Peter, what's your opinion? I think that was 
even talked about at Kernel Summit (or at least I thought of it there), but 
I've not understood if this is going to happen.
 

What can we do here? Can we probably create a project like the janitors 
so that we can report this kind of thing? Should we report here? How can 
we make a script to really benchmark the system and then say, since this 
guy sent a patch for the Pentium M CPU's, things are running slower? Or 
my SCSI drive is running slower since rc2, but not with rc1.


At least if the user notices this kind of things, then one will be able 
to google for patches for your controller for the last weeks and see if 
someone screwed up with a change they sent to the kernel.


In other words, kernel testing is not really easy for normal users, it 
can only really be benchmarked by the one that knows... Which are many, 
but not everyone.


And I really want to give my 2 cent on this.

.Alejandro
-
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: Is this a bug in linux-2.6.12 ipsec code function xfrm4_rcv_encap ??

[Patrick McHardy]

k8 s wrote:

I AM SORRY FOR THE PREVIOUS MAIL.
I am correcting my previous mail. 
Infact I see only One race(not three as was wrongly pointed out).

I commented out the section once again where the race might be.

 /
 Race Here . The Check(x->props.mode) is without Lock. What if setkey
-F is done at the same time on another processor freeing what x points
to.
 /


   if (x->props.mode) {


We hold a reference to the state, so it can't be freed.
-
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] Re: itimer oddness in 2.6.12

[George Anzinger]

Tom Marshall wrote:

On Fri, Jul 22, 2005 at 08:21:25PM +0100, Paulo Marques wrote:


Tom Marshall wrote:


The patch to fix "setitimer timer expires too early" is causing issues for
the Helix server.  We have a timer processs that updates the server's
timestamp on an itimer and it expects the signal to be delivered at roughly
the interval retrieved from getitimer.  This is very consistent on every
platform, including Linux up to 2.6.11, but breaks on 2.6.12.  On 2.6.12,
setting the itimer to 10ms and retrieving the actual interval from 
getitimer

reports 10.998ms, but the timer interrupts are consistently delivered at
roughly 11.998ms.  


Unfortunately, this is not so clear cut as it seems :(


Oops!  That patch is wrong.  The +1 should be applied to the initial 
interval _only_.  We KNOW when the repeating intervals start (i.e. at 
the jiffie edge) and don't need to adjust them.  The patch, however, 
incorrectly, rolls them all into one.  The attach patch should fix the 
problem.  Warnning, it compiles and boots, but I have not tested it.


George
--



Yes, I am sure that it is not a simple problem.  I am not a kernel developer
but I imagine that issues such as NTP adjustments would complicate this
issue.  I must also admit that I am not intimately familiar with the POSIX
spec regarding itimers.

Our current code does a setitimer followed by getitimer, then uses the
actual interval retrieved by getitimer to set a global timer delta.  On each
timer signal, it updates the notion of the current time by the timer delta. 
As mentioned, this works on every other platform (Solaris, BSD, HPUX, AIX,

DGUX, IRIX, Tru64, and Linux up to 2.6.11) but breaks on 2.6.12.




This is not an insurmountable problem for userspace.  It can be easily
solved by using gettimeofday in the timer interrupt instead of adding the
delta to the current time blindly.  No big deal.  I just wanted to point
this issue out and ensure that (1) it was a known issue, and (2) it is the
direction that the Linux kernel intends to take.  If so, no big deal and we
can modify the timer code to take that into account.



--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. 
Type: Defect Fix
Disposition: 
Description:

This changes setitimer as follows:
1. The repeating timer is figured using the requested time 
(not +1 as we know where we are in the jiffie).
2. The tests for interval too large are left to the time_val to jiffie code.


Signed-off-by: George Anzinger 
 itimer.c |   37 -
 1 files changed, 16 insertions(+), 21 deletions(-)

Index: linux-2.6.13-rc/kernel/itimer.c
===
--- linux-2.6.13-rc.orig/kernel/itimer.c
+++ linux-2.6.13-rc/kernel/itimer.c
@@ -112,28 +112,11 @@ asmlinkage long sys_getitimer(int which,
return error;
 }
 
-/*
- * Called with P->sighand->siglock held and P->signal->real_timer inactive.
- * If interval is nonzero, arm the timer for interval ticks from now.
- */
-static inline void it_real_arm(struct task_struct *p, unsigned long interval)
-{
-   p->signal->it_real_value = interval; /* XXX unnecessary field?? */
-   if (interval == 0)
-   return;
-   if (interval > (unsigned long) LONG_MAX)
-   interval = LONG_MAX;
-   /* the "+ 1" below makes sure that the timer doesn't go off before
-* the interval requested. This could happen if
-* time requested % (usecs per jiffy) is more than the usecs left
-* in the current jiffy */
-   p->signal->real_timer.expires = jiffies + interval + 1;
-   add_timer(>signal->real_timer);
-}
 
 void it_real_fn(unsigned long __data)
 {
struct task_struct * p = (struct task_struct *) __data;
+   unsigned long inc = p->signal->it_real_incr;
 
send_group_sig_info(SIGALRM, SEND_SIG_PRIV, p);
 
@@ -141,14 +124,23 @@ void it_real_fn(unsigned long __data)
 * Now restart the timer if necessary.  We don't need any locking
 * here because do_setitimer makes sure we have finished running
 * before it touches anything.
+* Note, we KNOW we are (or should be) at a jiffie edge here so 
+* we don't need the +1 stuff.  Also, we want to use the prior
+* expire value so as to not "slip" a jiffie if we are late.
+* Deal with requesting a time prior to "now" here rather than
+* in add_timer.
 */
-   it_real_arm(p, p->signal->it_real_incr);
+   if (!inc)
+   return;
+   while (time_before_eq(p->signal->real_timer.expires, jiffies))
+   p->signal->real_timer.expires += inc;
+   add_timer(>signal->real_timer);  
 }
 
 int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue)
 {
struct task_struct *tsk = current;
-   unsigned long val, interval;
+   unsigned long val, 

Re: PROBLEM: IDE Zip drive doesn't work under 2.6.12

[Grant Coady]

On Thu, 21 Jul 2005 11:21:05 -0400 (EDT), Jim Faulkner <[EMAIL PROTECTED]> 
wrote:
>
>Recently I upgraded from 2.6.11.11 to 2.6.12.3.  This morning I tried
>using my Zip drive... unfortunately it doesn't work under 2.6.12.3.  To
>verify that this was a kernel problem, I rebooted to 2.6.11.11.  Here's
>some relevant output using 2.6.11.11:

I too see this issue, but it doesn't go away on 2.6.11.12 for me, 
something is eating /dev/ nodes, writing to them, this doesn't 
happen in 2.4, so yet another "don't do that", or user-space, I 
haven't the foggiest.

fdisk sees the drive on 2.6, 2.4 sees it okay on same hardware

usb-storage also stomps /dev/sdX nodes on this and a different box, 
so something odd is happening with removable storage.

Grant.

-
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: Is this a bug in linux-2.6.12 ipsec code function xfrm4_rcv_encap ??

[k8 s]

I AM SORRY FOR THE PREVIOUS MAIL.
I am correcting my previous mail. 
Infact I see only One race(not three as was wrongly pointed out).
I commented out the section once again where the race might be.


On 7/23/05, k8 s <[EMAIL PROTECTED]> wrote:
> Hello,
> I see a possible race in linux-2.6.12 ipsec code function xfrm4_rcv_encap.
> I want to double check with the group.
> The issue is with SMP(mostly) or Preemptible Kernels.
> The race comes when someone flushes the SA's
> (setkey -Fexecuting  on another processor )
> while xfrm_rcv_encap is executing one processor.
> 
> Below is the function code.
> I am putting comments in the code where probably the race comes.
> correct me if I am wrong.
> 
> int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type)
> {
> int err;
> u32 spi, seq;
> struct sec_decap_state xfrm_vec[XFRM_MAX_DEPTH];
> struct xfrm_state *x;
> int xfrm_nr = 0;
> int decaps = 0;
> 
> if ((err = xfrm4_parse_spi(skb, skb->nh.iph->protocol, , )) 
> != 0)
> goto drop;
> 
> do {
> struct iphdr *iph = skb->nh.iph;
> 
> if (xfrm_nr == XFRM_MAX_DEPTH)
> goto drop;
> 
> x = xfrm_state_lookup((xfrm_address_t *)>daddr, spi,
> iph->protocol, AF_INET);
> 

> if (x == NULL)
> goto drop;
> 
> spin_lock(>lock);
> if (unlikely(x->km.state != XFRM_STATE_VALID))
> goto drop_unlock;
> 
> if (x->props.replay_window && xfrm_replay_check(x, seq))
> goto drop_unlock;
> 
> if (xfrm_state_check_expire(x))
> goto drop_unlock;
> 
> xfrm_vec[xfrm_nr].decap.decap_type = encap_type;
> if (x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb))
> goto drop_unlock;
> 
> /* only the first xfrm gets the encap type */
> encap_type = 0;
> 
> if (x->props.replay_window)
> xfrm_replay_advance(x, seq);
> 
> x->curlft.bytes += skb->len;
> x->curlft.packets++;
> 
> spin_unlock(>lock);
> 
> xfrm_vec[xfrm_nr++].xvec = x;
> 
> iph = skb->nh.iph;
> 
 /
 Race Here . The Check(x->props.mode) is without Lock. What if setkey
-F is done at the same time on another processor freeing what x points
to.
 /
> if (x->props.mode) {
> if (iph->protocol != IPPROTO_IPIP)
> goto drop;
> if (!pskb_may_pull(skb, sizeof(struct iphdr)))
> goto drop;
> if (skb_cloned(skb) &&
> pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
> goto drop;
> if (x->props.flags & XFRM_STATE_DECAP_DSCP)
> ipv4_copy_dscp(iph, skb->h.ipiph);
> if (!(x->props.flags & XFRM_STATE_NOECN))
> ipip_ecn_decapsulate(skb);
> skb->mac.raw = memmove(skb->data - skb->mac_len,
>skb->mac.raw, skb->mac_len);
> skb->nh.raw = skb->data;
> memset(&(IPCB(skb)->opt), 0, sizeof(struct 
> ip_options));
> decaps = 1;
> break;
> }
> 
> if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, , 
> )) < 0)
> goto drop;
> } while (!err);
> 
> /* Allocate new secpath or COW existing one. */
> 
> if (!skb->sp || atomic_read(>sp->refcnt) != 1) {
> struct sec_path *sp;
> sp = secpath_dup(skb->sp);
> if (!sp)
> goto drop;
> if (skb->sp)
> secpath_put(skb->sp);
> skb->sp = sp;
> }
> if (xfrm_nr + skb->sp->len > XFRM_MAX_DEPTH)
> goto drop;
> 
> memcpy(skb->sp->x+skb->sp->len, xfrm_vec, xfrm_nr*sizeof(struct
> sec_decap_state));
> skb->sp->len += xfrm_nr;
> 
> if (decaps) {
> if (!(skb->dev->flags_LOOPBACK)) {
> dst_release(skb->dst);
> skb->dst = NULL;
> }
> netif_rx(skb);
> return 0;
> } else {
> return -skb->nh.iph->protocol;
> }
> 
> drop_unlock:
> spin_unlock(>lock);
> xfrm_state_put(x);
> drop:
> while (--xfrm_nr >= 0)
> xfrm_state_put(xfrm_vec[xfrm_nr].xvec);
> 
> 

Re: kernel guide to space

[Jesper Juhl]

On 7/22/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/21/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > On 7/21/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, 21 Jul 2005, Jesper Juhl wrote:
> > >
> > > > On 7/21/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > > >> On Jul 20, 2005, at 20:45:21, Paul Jackson wrote:
> > > > [...snip...]
> > > >> *cough* TargetStatistics[TargetID].HostAdapterResetsCompleted *cough*
> > > >>
> > > >> I suspect linus would be willing to accept a few cleanup patches for 
> > > >> the
> > > >> BusLogic.c file.  Perhaps even one that renames BusLogic.c to 
> > > >> buslogic.c
> > > >> like all the other files in the source tree, instead of using nasty
> > > >> StudlyCaps all over :-D
> > > >>
> > > >
> > > > To avoid people doing duplicate work, I just want to say that I've
> > > > started doing a CodingStyle/whitespace/VariableAndFunctionNaming
> > > > cleanup of the BusLogic driver, I'll send the patches to LKML in a few
> > > > hours.
> > > >
> > > Are you going to get rid of the BusLogic* in front of every variable
> > > and function name? (yes please??)
> > Yes, I am.
> >
> > >  If so, you will need a few days!
> >
> > That may be, it sure turned into a bigger job than I had at first
> > expected. I'll break it into a few logical bits and submit them along
> > the way. First bits in a few hours - let's see how far I get :)
> >
> >
> > > It will take probably an hour to parse:
> > > struct BusLogic_FetchHostAdapterLocalRAMReguest
> >
> > Yeah, it takes time, but I'll get it done.
> >
> Heh, it takes a little more time than I had anticipated. I've got
> ~300Kb of patches here already, and I'm only about 30% done
> (estimated).
> It makes little sense to post the patches I have at this time, since
> they don't really finish the job and leave the files in a funky
> intermediate state, so I'll hold off on posting them untill I'm a
> little closer to the goal - hopefully tomorrow I'll finish it (right
> now I need to get some sleep) - I'll post the patches as soon as I'm
> done with them...
> 
Still moving forward with this, but not yet done. I think I'm going to
need one more day to finish this.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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/

[UPDATE PATCH] Add schedule_timeout_{interruptible,uninterruptible}_msecs() interfaces

[Nishanth Aravamudan]

On 22.07.2005 [20:31:55 -0400], Arjan van de Ven wrote:
> 
> > How does something like this look? If this looks ok, I'll send out
> > bunches of patches to add users of the new interfaces.
> 
> I'd drop the FASTCALL stuff... nowadays with regparm that's automatic
> and the cost of register-vs-stack isn't too big anyway
> 
> 
> Also I'd rather not add the non-msec ones... either you're raw and use
> HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> of adding an "in the middle" one. (Yes this means that several users
> need to be transformed to msecs but... I consider that progress ;)

Thanks for the feedback! Does this look better? I will be more than
happy to convert those users to msecs which should, btw :) I've been
waiting to add this interface so that the ones that couldn't use
msleep{,_interruptible}() because of wait-queues, can also be changed to
use milliseconds.

Hrm, I also noticed I typo'd the externs in sched.h. Fixed in the new
patch.

Description: Add schedule_timeout_msecs() and add wrappers for
interruptible/uninterruptible schedule_timeout_msecs() callers.

Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

---

 include/linux/sched.h |7 +++
 kernel/timer.c|   94 ++
 2 files changed, 100 insertions(+), 1 deletion(-)

diff -urpN 2.6.13-rc3/include/linux/sched.h 
2.6.13-rc3-new_interfaces/include/linux/sched.h
--- 2.6.13-rc3/include/linux/sched.h2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/include/linux/sched.h 2005-07-22 
18:06:36.0 -0700
@@ -181,8 +181,13 @@ extern void scheduler_tick(void);
 /* Is this address in the __sched functions? */
 extern int in_sched_functions(unsigned long addr);
 
-#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUT_MSECS  UINT_MAX
 extern signed long FASTCALL(schedule_timeout(signed long timeout));
+extern unsigned int schedule_timeout_msecs_interruptible
+   (unsigned int timeout_msecs);
+extern unsigned int schedule_timeout_msecs_uninterruptible
+   (unsigned int timeout_msecs);
 asmlinkage void schedule(void);
 
 struct namespace;
diff -urpN 2.6.13-rc3/kernel/timer.c 2.6.13-rc3-new_interfaces/kernel/timer.c
--- 2.6.13-rc3/kernel/timer.c   2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/kernel/timer.c2005-07-22 18:00:46.0 
-0700
@@ -1153,6 +1153,100 @@ fastcall signed long __sched schedule_ti
 
 EXPORT_SYMBOL(schedule_timeout);
 
+/*
+ * schedule_timeout_msecs - sleep until timeout
+ * @timeout_msecs: timeout value in milliseconds
+ *
+ * A human-time (but otherwise identical) alternative to
+ * schedule_timeout() The state, therefore, *does* need to be set before
+ * calling this function, but this function should *never* be called
+ * directly. Use the nice wrappers, schedule_{interruptible,
+ * uninterruptible}_timeout_msecs().
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+inline unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
+{
+   struct timer_list timer;
+   unsigned long expire_jifs;
+   signed long remaining_jifs;
+
+   if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
+   schedule();
+   goto out;
+   }
+
+   /*
+* msecs_to_jiffies() is a unit conversion, which truncates
+* (rounds down), so we need to add 1.
+*/
+   expire_jifs = jiffies + msecs_to_jiffies(timeout_msecs) + 1;
+
+   init_timer();
+   timer.expires = expire_jifs;
+   timer.data = (unsigned long) current;
+   timer.function = process_timeout;
+
+   add_timer();
+   schedule();
+   del_singleshot_timer_sync();
+
+   remaining_jifs = expire_jifs - jiffies;
+   /* if we have woken up *before* we have requested */
+   if (remaining_jifs > 0)
+   /*
+* don't need to add 1 here, even though there is
+* truncation, because we will add 1 if/when the value
+* is sent back in
+*/
+   timeout_msecs = jiffies_to_msecs(remaining_jifs);
+   else
+   timeout_msecs = 0;
+
+ out:
+   return timeout_msecs;
+}
+
+/**
+ * schedule_timeout_msecs_interruptible - sleep until timeout,
+ *  wait-queue event, or signal
+ * @timeout_msecs: timeout value in milliseconds
+ *
+ * A nice wrapper for the common
+ * set_current_state()/schedule_timeout_msecs() usage.  The state,
+ * therefore, does *not* need to be set before calling this function.
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+unsigned int __sched schedule_timeout_msecs_interruptible
+   (unsigned int timeout_msecs)
+{
+   

Is this a bug in linux-2.6.12 ipsec code function xfrm4_rcv_encap ??

[k8 s]

Hello,
I see a possible race in linux-2.6.12 ipsec code function xfrm4_rcv_encap.
I want to double check with the group.
The issue is with SMP(mostly) or Preemptible Kernels.
The race comes when someone flushes the SA's 
(setkey -Fexecuting  on another processor )
while xfrm_rcv_encap is executing one processor.

Below is the function code.
I am putting comments in the code where probably the race comes.
correct me if I am wrong.

int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type)
{
int err;
u32 spi, seq;
struct sec_decap_state xfrm_vec[XFRM_MAX_DEPTH];
struct xfrm_state *x;
int xfrm_nr = 0;
int decaps = 0;

if ((err = xfrm4_parse_spi(skb, skb->nh.iph->protocol, , )) != 
0)
goto drop;

do {
struct iphdr *iph = skb->nh.iph;

if (xfrm_nr == XFRM_MAX_DEPTH)
goto drop;

x = xfrm_state_lookup((xfrm_address_t *)>daddr, spi,
iph->protocol, AF_INET);

/***
First Race here . Check is being done without x being locked. What if
x becomes null because
of SA FLUSH (setkey -F) after the check.
***/
if (x == NULL)
goto drop;

spin_lock(>lock);
if (unlikely(x->km.state != XFRM_STATE_VALID))
goto drop_unlock;

if (x->props.replay_window && xfrm_replay_check(x, seq))
goto drop_unlock;

if (xfrm_state_check_expire(x))
goto drop_unlock;

xfrm_vec[xfrm_nr].decap.decap_type = encap_type;
if (x->type->input(x, &(xfrm_vec[xfrm_nr].decap), skb))
goto drop_unlock;

/* only the first xfrm gets the encap type */
encap_type = 0;

if (x->props.replay_window)
xfrm_replay_advance(x, seq);

x->curlft.bytes += skb->len;
x->curlft.packets++;

spin_unlock(>lock);

/***
 Second Race Here. Note the above line unlock already called.
***/
xfrm_vec[xfrm_nr++].xvec = x;

iph = skb->nh.iph;

/
Third Race Here . Again the Check is without Lock
/
if (x->props.mode) {
if (iph->protocol != IPPROTO_IPIP)
goto drop;
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
goto drop;
if (skb_cloned(skb) &&
pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
goto drop;
if (x->props.flags & XFRM_STATE_DECAP_DSCP)
ipv4_copy_dscp(iph, skb->h.ipiph);
if (!(x->props.flags & XFRM_STATE_NOECN))
ipip_ecn_decapsulate(skb);
skb->mac.raw = memmove(skb->data - skb->mac_len,
   skb->mac.raw, skb->mac_len);
skb->nh.raw = skb->data;
memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options));
decaps = 1;
break;
}

if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, , 
)) < 0)
goto drop;
} while (!err);

/* Allocate new secpath or COW existing one. */

if (!skb->sp || atomic_read(>sp->refcnt) != 1) {
struct sec_path *sp;
sp = secpath_dup(skb->sp);
if (!sp)
goto drop;
if (skb->sp)
secpath_put(skb->sp);
skb->sp = sp;
}
if (xfrm_nr + skb->sp->len > XFRM_MAX_DEPTH)
goto drop;

memcpy(skb->sp->x+skb->sp->len, xfrm_vec, xfrm_nr*sizeof(struct
sec_decap_state));
skb->sp->len += xfrm_nr;

if (decaps) {
if (!(skb->dev->flags_LOOPBACK)) {
dst_release(skb->dst);
skb->dst = NULL;
}
netif_rx(skb);
return 0;
} else {
return -skb->nh.iph->protocol;
}

drop_unlock:
spin_unlock(>lock);
xfrm_state_put(x);
drop:
while (--xfrm_nr >= 0)
xfrm_state_put(xfrm_vec[xfrm_nr].xvec);

kfree_skb(skb);
return 0;
}





I am just guessing.
If I am wrong I 

Re: Giving developers clue how many testers verified certain kernel version

[H. Peter Anvin]

David Lang wrote:

On Sat, 23 Jul 2005, Blaisorblade wrote:

IMHO, I think that publishing statistics about kernel patches 
downloads would
be a very Good Thing(tm) to do. Peter, what's your opinion? I think 
that was
even talked about at Kernel Summit (or at least I thought of it 
there), but

I've not understood if this is going to happen.



remember that most downloads will be from mirrors, and they don't get 
stats from them.


David Lang



That, plus there is http+ftp+rsync (not to mention git downloads, etc.) 
and the noise caused by other sites mirroring *us*.


-hpa
-
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: Giving developers clue how many testers verified certain kernel version

[David Lang]

On Sat, 23 Jul 2005, Blaisorblade wrote:


IMHO, I think that publishing statistics about kernel patches downloads would
be a very Good Thing(tm) to do. Peter, what's your opinion? I think that was
even talked about at Kernel Summit (or at least I thought of it there), but
I've not understood if this is going to happen.


remember that most downloads will be from mirrors, and they don't get 
stats from them.


David Lang

--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)

[Pavel Machek]

Hi!

> > Unfortunately, if you only get printk() working after you ran
> > userspace app... well it makes debugging things like SATA
> > "interesting". So I quite like this patch.
> 
> Most interesting laptop vendors have at least one model in each range
> with a serial port, which makes this sort of thing a bit easier. 

Well, we have debugged with beeps, but... It would be cool if someone
got usb debug mode working but... and there are hardware debuggers.

Anyway, this patch is really good, and enables S3 to work on more
machines. Thats good. It is not intrusive and I'll probably (try to)
push it.

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

Re: Giving developers clue how many testers verified certain kernel version

[Blaisorblade]

Adrian Bunk  stusta.de> writes:
> On Thu, Jul 21, 2005 at 09:40:43PM -0500, Alejandro Bonilla wrote:
> > 
> >How do we know that something is OK or wrong? just by the fact that 
> > it works or not, it doesn't mean like is OK.
> > 
> > There has to be a process for any user to be able to verify and study a 
> > problem. We don't have that yet.

> If the user doesn't notice the difference then there's no problem for 
> him.
Some performance regressions aren't easily noticeable without benchmarks... 
and we've had people claiming unnoticed regressions since 2.6.2 
(http://kerneltrap.org/node/4940)
> If there's a problem the user notices, then the process is to send an 
> email to linux-kernel and/or open a bug in the kernel Bugzilla and 
> follow the "please send the output of foo" and "please test patch bar" 
> instructions.

> What comes nearest to what you are talking about is that you run LTP 
> and/or various benchmarks against every -git and every -mm kernel and 
> report regressions. But this is sinply a task someone could do (and I 
> don't know how much of it is already done e.g. at OSDL), and not 
> something every user could contribute to.

Forgot drivers testing? That is where most of the bugs are hidden, and where 
wide user testing is definitely needed because of the various hardware bugs 
and different configurations existing in real world.

IMHO, I think that publishing statistics about kernel patches downloads would 
be a very Good Thing(tm) to do. Peter, what's your opinion? I think that was 
even talked about at Kernel Summit (or at least I thought of it there), but 
I've not understood if this is going to happen.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
-
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] reset VGA adapters via BIOS on resume... (non-fbdev/con)

[Matthew Garrett]

Pavel Machek <[EMAIL PROTECTED]> wrote:

> Unfortunately, if you only get printk() working after you ran
> userspace app... well it makes debugging things like SATA
> "interesting". So I quite like this patch.

Most interesting laptop vendors have at least one model in each range
with a serial port, which makes this sort of thing a bit easier. 

> If your BIOS does something wrong, well... your machine crashes.

I think it's hard to define it as "something wrong" - there's no reason
for BIOS authors to support the OS calling BIOS setup code after the
machine has booted. Thinkpads seem to manage this fine, Sonys tend to be
less good at it. Using the VBE mode setting code tends to be more
reliable, and is pretty much guaranteed to be there even after boot.

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

Re: 2.6.13-rc3: swsusp works (TP 600X)

[Pavel Machek]

Hi!

> swsusp now mostly works on my TP 600X.  If I don't eject the pcmcia card
> (usually a prism54 wireless card), swsusp begins the process of
> hibernation, but never gets to the writing pages part.  The eth0 somehow
> tries to reload the firmware (as if it's been woken up), and then
> everything hangs.  If I eject the card and (for safety) stop
> /etc/init.d/pcmcia, then swsusp writes out the memory to swap, and
> waking up works fine.  Thanks for all the improvements!
> 
> Is there debugging I can do in order to help get the pcmcia system
> hibernating automagically?

Well, it really may be the firmware loading. Add some printks to
confirm it, then fix it.

> One other glitch is that pdnsd (a nameserver caching daemon) has crashed
> when the system wakes up from swsusp.  It also happens when waking up
> from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
> Many people have said mysql also does not suspend well.  Is their use of
> a named pipe or socket causing the problem?

No idea, strace?
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
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] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces

[Arjan van de Ven]

> How does something like this look? If this looks ok, I'll send out
> bunches of patches to add users of the new interfaces.

I'd drop the FASTCALL stuff... nowadays with regparm that's automatic
and the cost of register-vs-stack isn't too big anyway


Also I'd rather not add the non-msec ones... either you're raw and use
HZ, or you are "cooked" and use the msec variant.. I dont' see the point
of adding an "in the middle" one. (Yes this means that several users
need to be transformed to msecs but... I consider that progress ;)

-
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: fix suspend/resume irq request free for yenta..

[Pavel Machek]

Hi!

> > Without this patch my laptop fails to resume from suspend to RAM...
> > 
> > It applies against a pretty recent 2.6.13-rc3 from git..
> > 
> 
> Hi,
> 
> Is it necessary to do free_irq for suspend? Shouldn't disable_irq
> be enough?

Due to recent changes in ACPI, yes, it is neccessary.
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
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] reset VGA adapters via BIOS on resume... (non-fbdev/con)

[Pavel Machek]

Hi!

> > At OLS at lot of people were giving out about cards not resuming,
> > so using a patch from Michael Marineau and help from lots of people
> > sitting around in a circle at OLS I've gotten a patch that restores video
> > on my laptop by going into real mode and re-posting the BIOS during
> > resume,
> 
> On laptops, the code at c000:0003 may jump to BIOS code that isn't
> present after system boot. In userspace, this isn't too much of a
> problem - the userspace code tends to just fall over rather than hanging
> the machine. What happens if the kernel hits illegal or inappropriate
> code on resume?
> 
> I'm still fairly convinced that the best approach here is to carry it
> out in userspace, though this may require some support for asking
> framebuffers not to try to print anything until userspace is running.
> The only "real" solution is for the framebuffer drivers to know how to
> program the chip from scratch.

Unfortunately, if you only get printk() working after you ran
userspace app... well it makes debugging things like SATA
"interesting". So I quite like this patch.

If your BIOS does something wrong, well... your machine crashes.

Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 2/2] Touchscreen support for sharp sl-5500

[Pavel Machek]

This adds support for touchscreen on Sharp Zaurus sl-5500. Vojtech,
please apply,

Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -36,6 +36,15 @@ config TOUCHSCREEN_CORGI
  To compile this driver as a module, choose M here: the
  module will be called ads7846_ts.
 
+config TOUCHSCREEN_COLLIE
+   tristate "Collie touchscreen (for Sharp SL-5500)"
+   depends on MCP_UCB1200
+   help
+ Say Y here to enable the driver for the touchscreen on the 
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
 config TOUCHSCREEN_GUNZE
tristate "Gunze AHL-51S touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -6,6 +6,7 @@
 
 obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
 obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
 obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
 obj-$(CONFIG_TOUCHSCREEN_ELO)  += elo.o
 obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
diff --git a/drivers/input/touchscreen/collie_ts.c 
b/drivers/input/touchscreen/collie_ts.c
new file mode 100644
--- /dev/null
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -0,0 +1,377 @@
+/*
+ *  linux/drivers/input/touchscreen/collie_ts.c
+ *
+ *  Copyright (C) 2001 Russell King, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 21-Jan-2002 <[EMAIL PROTECTED]> :
+ *
+ * Added support for synchronous A/D mode. This mode is useful to
+ * avoid noise induced in the touchpanel by the LCD, provided that
+ * the UCB1x00 has a valid LCD sync signal routed to its ADCSYNC pin.
+ * It is important to note that the signal connected to the ADCSYNC
+ * pin should provide pulses even when the LCD is blanked, otherwise
+ * a pen touch needed to unblank the LCD will never be read.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+
+struct ucb1x00_ts {
+   struct input_devidev;
+   struct ucb1x00  *ucb;
+
+   struct semaphoreirq_wait;
+   struct completion   init_exit;
+   struct task_struct  *rtask;
+   u16 x_res;
+   u16 y_res;
+
+   int restart:1;
+   int adcsync:1;
+};
+
+/*
+ * Switch to interrupt mode.
+ */
+static inline void ucb1x00_ts_mode_int(struct ucb1x00_ts *ts)
+{
+   int val = UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+ UCB_TS_CR_MODE_INT;
+   if (ts->ucb->id == UCB_ID_1400_BUGGY)
+   val &= ~(UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW);
+   ucb1x00_reg_write(ts->ucb, UCB_TS_CR, val);
+}
+
+/*
+ * Switch to pressure mode, and read pressure.  We don't need to wait
+ * here, since both plates are being driven.
+ */
+static inline unsigned int ucb1x00_ts_read_pressure(struct ucb1x00_ts *ts)
+{
+   ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+   UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+   UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+   UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+
+   return ucb1x00_adc_read(ts->ucb, UCB_ADC_INP_TSPY, ts->adcsync);
+}
+
+/*
+ * Switch to X position mode and measure Y plate.  We switch the plate
+ * configuration in pressure mode, then switch to position mode.  This
+ * gives a faster response time.  Even so, we need to wait about 55us
+ * for things to stabilise.
+ */
+static inline unsigned int ucb1x00_ts_read_xpos(struct ucb1x00_ts *ts)
+{
+   ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+   UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+   UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+   ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+   UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+   UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+   ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+   UCB_TS_CR_TSMX_GND | UCB_TS_CR_TSPX_POW |
+   UCB_TS_CR_MODE_POS | UCB_TS_CR_BIAS_ENA);
+
+   udelay(55);
+
+   return ucb1x00_adc_read(ts->ucb, UCB_ADC_INP_TSPY, ts->adcsync);
+}
+
+/*
+ * Switch to Y position mode and measure X plate.  We switch the plate
+ * configuration in pressure mode, then switch to position mode.  This
+ * gives a faster response time.  Even so, we need to wait about 55us
+ * for 

[PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces

[Nishanth Aravamudan]

On 08.07.2005 [16:08:24 -0700], Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
> >
> > @@ -655,7 +655,7 @@ i2QueueCommands(int type, i2ChanStrPtr p
> > timeout--;   // So negative values == forever
> > 
> > if (!in_interrupt()) {
> 
> I worry about what this driver is trying to do...
> 
> > -   current->state = TASK_INTERRUPTIBLE;
> > +   set_current_state(TASK_INTERRUPTIBLE);
> > schedule_timeout(1);// short nap 
> 
> We do this all over the place.  Adding new schedule_timeout_interruptible()
> and schedule_timeout_uninterruptible() would reduce kernel size and neaten
> things up.

How does something like this look? If this looks ok, I'll send out
bunches of patches to add users of the new interfaces.

Description: Add wrappers for interruptible/uninterruptible
schedule_timeout() callers. Also add millisecond equivalents.

Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

---

 include/linux/sched.h |   11 
 kernel/timer.c|  125 ++
 2 files changed, 135 insertions(+), 1 deletion(-)

diff -urpN 2.6.13-rc3/include/linux/sched.h 
2.6.13-rc3-new_interfaces/include/linux/sched.h
--- 2.6.13-rc3/include/linux/sched.h2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/include/linux/sched.h 2005-07-22 
16:28:47.0 -0700
@@ -181,8 +181,17 @@ extern void scheduler_tick(void);
 /* Is this address in the __sched functions? */
 extern int in_sched_functions(unsigned long addr);
 
-#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
+#defineMAX_SCHEDULE_TIMEOUT_MSECS  UINT_MAX
 extern signed long FASTCALL(schedule_timeout(signed long timeout));
+extern signed long FASTCALL(schedule_timeout_interruptible
+   (signed long timeout));
+extern signed long FASTCALL(schedule_timeout_uninterruptible
+   (signed long timeout));
+extern unsigned int FASTCALL(schedule_timeout_interruptible_msecs
+   (unsigned int timeout_msecs));
+extern unsigned int FASTCALL(schedule_timeout_uninterruptible_msecs
+   (unsigned int timeout_msecs));
 asmlinkage void schedule(void);
 
 struct namespace;
diff -urpN 2.6.13-rc3/kernel/timer.c 2.6.13-rc3-new_interfaces/kernel/timer.c
--- 2.6.13-rc3/kernel/timer.c   2005-07-13 15:52:14.0 -0700
+++ 2.6.13-rc3-new_interfaces/kernel/timer.c2005-07-22 16:31:31.0 
-0700
@@ -1153,6 +1153,131 @@ fastcall signed long __sched schedule_ti
 
 EXPORT_SYMBOL(schedule_timeout);
 
+/**
+ * schedule_timeout_interruptible - sleep until timeout, wait-queue
+ *  event or signal
+ * @timeout: timeout value in jiffies
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+fastcall signed long __sched schedule_timeout_interruptible(signed long 
timeout)
+{
+   set_current_state(TASK_INTERRUPTIBLE);
+   return schedule_timeout(timeout);
+}
+
+EXPORT_SYMBOL(schedule_timeout_interruptible);
+
+/**
+ * schedule_timeout_uninterruptible - sleep until timeout or wait-queue
+ * event
+ * @timeout: timeout value in jiffies
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+fastcall signed long __sched schedule_timeout_uninterruptible(signed long 
timeout)
+{
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   return schedule_timeout(timeout);
+}
+
+EXPORT_SYMBOL(schedule_timeout_uninterruptible);
+
+/*
+ * schedule_timeout_msecs - sleep until timeout
+ * @timeout_msecs: timeout value in milliseconds
+ *
+ * A human-time (but otherwise identical) alternative to
+ * schedule_timeout() The state, therefore, *does* need to be set before
+ * calling this function, but this function should *never* be called
+ * directly. Use the nice wrappers, schedule_{interruptible,
+ * uninterruptible}_timeout_msecs().
+ *
+ * See the comment for schedule_timeout() for details.
+ */
+fastcall inline unsigned int __sched schedule_timeout_msecs
+   (unsigned int timeout_msecs)
+{
+   struct timer_list timer;
+   unsigned long expire_jifs;
+   signed long remaining_jifs;
+
+   if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
+   schedule();
+   goto out;
+   }
+
+   /*
+* msecs_to_jiffies() is a unit conversion, which truncates
+* (rounds down), so we need to add 1.
+*/
+   expire_jifs = jiffies + msecs_to_jiffies(timeout_msecs) + 1;
+
+   init_timer();
+   timer.expires = expire_jifs;
+   timer.data = (unsigned long) current;
+   timer.function = process_timeout;
+
+   add_timer();
+   schedule();
+   del_singleshot_timer_sync();
+
+   

Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)

[Mark Hahn]

> > actually, let me also say that CKRM is on a continuum that includes 
> > current (global) /proc tuning for various subsystems, ulimits, and 
> > at the other end, Xen/VMM's.  it's conceivable that CKRM could wind up
> > being useful and fast enough to subsume the current global and per-proc
> > tunables.  after all, there are MANY places where the kernel tries to 
> > maintain some sort of context to allow it to tune/throttle/readahead
> > based on some process-linked context.  "embracing and extending"
> > those could make CKRM attractive to people outside the mainframe market.
> 
>   Seems like an excellent suggestion to me! Yeah, it may be possible to
> maintain the context the kernel keeps on a per-class basis instead of
> globally or per-process. 

right, but are the CKRM people ready to take this on?  for instance,
I just grepped 'throttle' in kernel/mm and found a per-task RM in 
page-writeback.c.  it even has a vaguely class-oriented logic, since
it exempts RT tasks.  if CKRM can become a way to make this stuff 
cleaner and more effective (again, for normal tasks), then great.
but bolting on a big new different, intrusive mechanism that slows
down all normal jobs by 3% just so someone can run 10K mostly-idle
guests on a giant Power box, well, that's gross.

> The real question is what constitutes a useful
> "extension" :).

if CKRM is just extensions, I think it should be an external patch.
if it provides a path towards unifying the many disparate RM mechanisms
already in the kernel, great!

>   I was thinking that per-class nice values might be a good place to
> start as well. One advantage of per-class as opposed to per-process nice
> is the class is less transient than the process since its lifetime is
> determined solely by the system administrator.

but the Linux RM needs to subsume traditional Unix process groups,
and inherited nice/schd class, and even CAP_ stuff.  I think CKRM
could start to do this, since classes are very general.
but merely adding a new, incompatible feature is just Not A Good Idea.

regards, mark hahn.

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

2.6.13-rc3: swsusp works (TP 600X)

[Sanjoy Mahajan]

swsusp now mostly works on my TP 600X.  If I don't eject the pcmcia card
(usually a prism54 wireless card), swsusp begins the process of
hibernation, but never gets to the writing pages part.  The eth0 somehow
tries to reload the firmware (as if it's been woken up), and then
everything hangs.  If I eject the card and (for safety) stop
/etc/init.d/pcmcia, then swsusp writes out the memory to swap, and
waking up works fine.  Thanks for all the improvements!

Is there debugging I can do in order to help get the pcmcia system
hibernating automagically?

One other glitch is that pdnsd (a nameserver caching daemon) has crashed
when the system wakes up from swsusp.  It also happens when waking up
from S3, which was working with 2.6.11.4 although not with 2.6.13-rc3.
Many people have said mysql also does not suspend well.  Is their use of
a named pipe or socket causing the problem?

System: TP 600X, 2.6.13-rc3 vanilla kernel, fixed DSDT that I used to
get S3 working with 2.6.11.4 (see
 for the DSDT),
booted with 
  idebus=66 apm=off acpi=force pci=noacpi acpi_sleep=s3_bios

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal
-
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: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

[Jirka Kosina]

On Fri, 22 Jul 2005, linux-os (Dick Johnson) wrote:

> Seems to be readable and starts with 'ELF'. It's something the the 'C'
> runtime may library use to make syscalls to the kernel. Older libraries
> used interrupt 0x80, newer ones may use this. Roland McGrath has made
> patches to this segment so maybe he knows.

This page is a vsyscall page. See http://lwn.net/Articles/30258/

-- 
JiKos.
-
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: Memory Management

[Márcio Oliveira]

Roger Heflin wrote:


I have seen RH3.0 crash on 32GB systems because it has too
much memory tied up in write cache.  It required update 2 
(this was a while ago) and a change of a parameter in /proc

to prevent the crash, it was because of a overagressive
write caching change RH implemented in the kernel resulted
in the crash.  This crash was an OOM related crash.  To
duplicate the bug, you booted the machine and ran a dd
to create a very large file filling the disk.

We did test and did determine that it did not appear to have
the issue if you had less than 28GB of ram, this was on an
itanium machine, so I don't know if it occurs on other arches,
and if it occurs at the same memory limits on the other arches
either.

   Roger



 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
Márcio Oliveira

Sent: Friday, July 22, 2005 2:42 PM
To: Neil Horman
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Memory Management

Neil Horman wrote:

   


On Fri, Jul 22, 2005 at 11:32:52AM -0300, Márcio Oliveira wrote:


 


Neil Horman wrote:

  

   


On Thu, Jul 21, 2005 at 10:40:54AM -0300, Márcio Oliveira wrote:




 


http://people.redhat.com/nhorman/papers/rhel3_vm.pdf
I wrote this with norm awhile back.  It may help you out.
Regards
Neil


  



 


Neil,

Thanks.~10-12GB of total RAM (16GB) are

How can Proc virtual memory parameters like 
   

inactive_clean_percent, 
   

overcommit_memory, overcommit_ratio and page_cache help 
   

me to solve 
   

/ reduce Out Of Memory conditions on servers with 16GB 
   

RAM and lots 
   


of GB swap?



  

   

I wouldn't touch memory overcommit if you are already 
 

seeing out of 
   

memory issues.  If you are using lots of pagecache, I 
 

would suggest 
   

increasing inactive_clean percent, reducing the 
 

pagecahce.max value, 
   

and modifying the bdflush parameters in the above document 
 

such that 
   

bdflush runs sooner, more often, and does more work per 
 

iteration.  
   

This will help you move data in pagecache back to disk more 
aggressively so that memory will be available for other purposes, 
like heap allocations. Also if you're using a Red Hat 
 

kernel and you 
   

have 16GB of ram in your system, you're a good candidate for the 
hugemem kernel.  Rather than a straightforward out of memory 
condition, you may be seeing a exhaustion of your kernels address 
space (check LowFree in /proc/meminfo).  In this even the hugemem 
kernel will help you in that it increases your Low Memory address 
space from 1GB to 4GB, preventing some OOM conditions.



 

Kernel does not free cached memory (~10-12GB of total RAM 
   

- 16GB). Is 
   


there some way to force the kernel to free cached memory?
   

Cached memory is freed on demand.  Just because its listed 
 

under the 
   


cached line
below doesn't mean it can't be freed and used for another 
 

purpose.  
   


Implement
the tunings above, and your situation should improve.

Regards
Neil





 


/proc/meminfo:

 total:used:free:  shared: buffers:  cached:
Mem:16603488256 1652632 801546240 
   


70651904 13194563584
   


Swap:   17174257664 11771904 17162485760
MemTotal: 16214344 kB
MemFree: 78276 kB
Buffers: 68996 kB
Cached:   12874808 kB

Thanks to all.

Marcio.


  

   


Neil,

Thanks for the answers!

The following lines are the Out Of Memory log:

Jul 20 13:45:44 server kernel: Out of Memory: Killed 
   


process 23716 (oracle).
   


Jul 20 13:45:44 server kernel: Fixed up OOM kill of mm-less task
Jul 20 13:45:45 server su(pam_unix)[3848]: session closed 
   


for user root
   


Jul 20 13:45:48 server kernel: Mem-info:
Jul 20 13:45:48 server kernel: Zone:DMA freepages:  1884 min: 0 
low: 0 high: 0
Jul 20 13:45:48 server kernel: Zone:Normal freepages:  1084 
   

min:  1279 
   


low:  4544 high:  6304
Jul 20 13:45:48 server kernel: Zone:HighMem 
   

freepages:386679 min:   255 
   


low: 61952 high: 92928
Jul 20 13:45:48 server kernel: Free pages:  389647 
   


(386679 HighMem)
   

Jul 20 13:45:48 server kernel: ( Active: 2259787/488777, 
inactive_laundry: 244282, inactive_clean: 244366, free: 389647 )

Jul 20 13:45:48 server kernel:   aa:0 ac:0 id:0 il:0 ic:0 fr:1884
Jul 20 13:45:48 server kernel:   aa:1620 ac:1801 id:231 
   


il:15 ic:0 fr:1085
   

Jul 20 13:45:48 server kernel:   aa:1099230 ac:1157136 id:488536 
il:244277 ic:244366 fr:386679
Jul 20 13:45:48 server kernel: 0*4kB 0*8kB 1*16kB 1*32kB 
   

1*64kB 0*128kB 
   

1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 7536kB)Jul 20 13:45:48 
server kernel: 55*4kB 9*8kB 19*16kB 9*32kB 0*64kB 1*128kB 1*256kB 
0*512kB 1*1024kB 1*2048kB 

Re: Merging relayfs?

[Karim Yaghmour]

Tom Zanussi wrote:
> - removed the deliver() callback
> - removed the relay_commit() function

This breaks LTT. Any reason why this needed to be removed? In the end,
the code will just end up being duplicated in ltt and all other users.
IOW, this is not some potential future use, but something that's
currently being used.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
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: Giving developers clue how many testers verified certain kernel version

[Adrian Bunk]

On Thu, Jul 21, 2005 at 09:40:43PM -0500, Alejandro Bonilla wrote:
>...
>How does one check if hotplug is working better than before? How do 
> I test the fact that a performance issue seen in the driver is now fixed 
> for me or most of users? How do I get back to a bugzilla and tell that 
> there is a bug somewhere when one can't really know if that is the way 
> it works but is simply ugly, or if there is really a bug?
> 
>My point is that a user like me, can't really get back to this 
> mailing list and say "hey, since 2.6.13-rc1, my PCI bus is having an 
> additional 1ms of latency" We don't really have a process to follow and 
> then be able to say "ahha, so this is different" and then report the 
> problem, even if we can't fix it because of our C and kernel skills.
> 
>How do we know that something is OK or wrong? just by the fact that 
> it works or not, it doesn't mean like is OK.
> 
> There has to be a process for any user to be able to verify and study a 
> problem. We don't have that yet.

If the user doesn't notice the difference then there's no problem for 
him.

If there's a problem the user notices, then the process is to send an 
email to linux-kernel and/or open a bug in the kernel Bugzilla and 
follow the "please send the output of foo" and "please test patch bar" 
instructions.

What comes nearest to what you are talking about is that you run LTP 
and/or various benchmarks against every -git and every -mm kernel and 
report regressions. But this is sinply a task someone could do (and I 
don't know how much of it is already done e.g. at OSDL), and not 
something every user could contribute to.

> .Alejandro

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 2.6.13-rc3a] i386: inline restore_fpu

[Linus Torvalds]

On Thu, 21 Jul 2005, Chuck Ebbert wrote:
> 
>   This patch makes restore_fpu() an inline.  When L1/L2 cache are saturated
> it makes a measurable difference.

I've now pushed out an alternative fix for this, which imho is much 
cleaner.

We've long had infrastructure for "alternative asm instructions" that are 
conditional on CPU features, and I just made restore_fpu() use that 
instead:

/*
 * The "nop" is needed to make the instructions the same
 * length.
 */
#define restore_fpu(tsk)\
alternative_input(  \
"nop ; frstor %1",  \
"fxrstor %1",   \
X86_FEATURE_FXSR,   \
"m" ((tsk)->thread.i387.fsave))

which not only makes it inline, but makes it a single instruction instead 
of the mess it was before.

Now, we should do the same for "fnsave ; fwait" vs "fxsave ; fnclex" too,
but I was lazy. If somebody wants to try that, it would need an 
"alternative_output()" define but should otherwise be trivial too.

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

Re: [PATCH] serverworks should not take ahold of megaraid'd controllers

[Darrick J. Wong]

Arjan, Alan:

I didn't know that dmraid supports MegaIDE nowadays.  Thanks for the
tipoff, and I apologize for the unnecessary traffic.  I'll look into dmraid.

--D

Alan Cox wrote:
> On Iau, 2005-07-21 at 15:37 -0700, Darrick J. Wong wrote:
> 
>>I've noticed what might be a small bug with the serverworks driver in
>>2.6.12.3.  The IBM HS20 blade has a ServerWorks CSB6 IDE controller with
>>an optional LSI MegaIDE RAID BIOS (BIOS assisted software raid, iow).
> 
> 
> With a binary only proprietary driver.
> 
> 
>>(ServerWorks) to IBM.  However, the serverworks driver doesn't notice
>>this and will attach to the controller anyway, thus allowing raw access
>>to the disks in the RAID.  An unsuspecting user can then read and write
>>whatever they want to the drive, which could very well degrade or
>>destroy the array, which is clearly not desirable behavior.
> 
> 
> It may be appropriate for some vendor situations but it isn't
> appropriate for the base kernel to default to assuming the user wants to
> use binary only drivers instead of dmraid. Especially as the raid
> formats for this hardware are partially known despite no assistance I
> know of from the vendor.
> 
> Alan
> 
> 


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)

[Matthew Garrett]

Dave Airlie <[EMAIL PROTECTED]> wrote:

>   At OLS at lot of people were giving out about cards not resuming,
> so using a patch from Michael Marineau and help from lots of people
> sitting around in a circle at OLS I've gotten a patch that restores video
> on my laptop by going into real mode and re-posting the BIOS during
> resume,

On laptops, the code at c000:0003 may jump to BIOS code that isn't
present after system boot. In userspace, this isn't too much of a
problem - the userspace code tends to just fall over rather than hanging
the machine. What happens if the kernel hits illegal or inappropriate
code on resume?

I'm still fairly convinced that the best approach here is to carry it
out in userspace, though this may require some support for asking
framebuffers not to try to print anything until userspace is running.
The only "real" solution is for the framebuffer drivers to know how to
program the chip from scratch.

-- 
Matthew Garrett | [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: fix suspend/resume irq request free for yenta..

[Dmitry Torokhov]

On Friday 22 July 2005 17:33, Dave Airlie wrote:
> 
> Without this patch my laptop fails to resume from suspend to RAM...
> 
> It applies against a pretty recent 2.6.13-rc3 from git..
> 

Hi,

Is it necessary to do free_irq for suspend? Shouldn't disable_irq
be enough?

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

Re: Giving developers clue how many testers verified certain kernel version

[Adrian Bunk]

On Fri, Jul 22, 2005 at 03:34:09AM +0200, Martin MOKREJ? wrote:

> Hi,

Hi Martin,

>  I think the discussion going on here in another thread about lack
> of positive information on how many testers successfully tested certain
> kernel version can be easily solved with real solution.
> 
>  How about opening separate "project" in bugzilla.kernel.org named
> kernel-testers or whatever, where whenever cvs/svn/bk gatekeepers
> would release some kernel patch, would open an empty "bugreport"
> for that version, say for 2.6.13-rc3-git4.
> 
>  Anybody willing to join the crew who cared to download the patch
> and tested the kernel would post just a single comment/follow-up
> to _that_ "bugreport" with either "positive" rating or URL
> of his own bugreport with some new bug. When the bug get's closed
> it would be immediately obvious in the 2.6.13-rc3-git4 bug ticket
> as that bug will be striked-through as closed.
> 
>  Then, we could easily just browse through and see that 2.6.13-rc2
> was tested by 33 fellows while 3 of them found a problem and 2 such
> problems were closed since then.
>...

most likely, only a small minory of the people downloading a patch would 
register at such a "project".

The important part of the work, the bug reports, can already today go to 
lnux-kernel and/or the Bugzilla.

You'd spend efforts for such a "project" that would only produce some 
numbers of questionable value.

> Martin

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: Why build empty object files in drivers/media?

[Sam Ravnborg]

On Fri, Jul 22, 2005 at 11:18:13PM +0200, Olaf Dietsche wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
> 
> > +obj-$(CONFIG_VIDEO_DEV) := video/
> > +obj-$(CONFIG_VIDEO_DEV) := radio/
> 
>   s/VIDEO/RADIO/

If you look at drivers/media/radio/Kconfig you will see that the above
is coorect. Thre is no CONFIG_RADIO_DEV.

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

fix suspend/resume irq request free for yenta..

[Dave Airlie]

Without this patch my laptop fails to resume from suspend to RAM...

It applies against a pretty recent 2.6.13-rc3 from git..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -872,10 +872,20 @@ static irqreturn_t yenta_probe_handler(i
return IRQ_NONE;
 }
 
+static int yenta_request_irq(struct yenta_socket *socket)
+{
+   if (request_irq(socket->cb_irq, yenta_probe_handler, SA_SHIRQ, "yenta", 
socket)) {
+   printk(KERN_WARNING "Yenta: request_irq() in 
yenta_probe_cb_irq() failed!\n");
+   return -1;
+   }
+   return 0;
+}
+
 /* probes the PCI interrupt, use only on override functions */
 static int yenta_probe_cb_irq(struct yenta_socket *socket)
 {
u16 bridge_ctrl;
+   int ret;
 
if (!socket->cb_irq)
return -1;
@@ -887,10 +897,9 @@ static int yenta_probe_cb_irq(struct yen
bridge_ctrl &= ~CB_BRIDGE_INTR;
config_writew(socket, CB_BRIDGE_CONTROL, bridge_ctrl);
 
-   if (request_irq(socket->cb_irq, yenta_probe_handler, SA_SHIRQ, "yenta", 
socket)) {
-   printk(KERN_WARNING "Yenta: request_irq() in 
yenta_probe_cb_irq() failed!\n");
-   return -1;
-   }
+   ret = yenta_request_irq(socket);
+   if (ret==-1)
+   return ret;
 
/* generate interrupt, wait */
exca_writeb(socket, I365_CSCINT, I365_CSC_STSCHG);
@@ -1101,6 +1110,7 @@ static int yenta_dev_suspend (struct pci
if (socket->type && socket->type->save_state)
socket->type->save_state(socket);
 
+   free_irq(dev->irq, socket);
/* FIXME: pci_save_state needs to have a better interface */
pci_save_state(dev);
pci_read_config_dword(dev, 16*4, >saved_state[0]);
@@ -1131,6 +1141,7 @@ static int yenta_dev_resume (struct pci_
pci_write_config_dword(dev, 17*4, socket->saved_state[1]);
pci_enable_device(dev);
pci_set_master(dev);
+   yenta_request_irq(socket);
 
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);

[2.6 patch] drivers/block/sx8.c: fix warnings with -Wundef

[Adrian Bunk]

This patch fixes the following warnings with -Wundef:

<--  snip  -->

...
  CC  drivers/block/sx8.o
drivers/block/sx8.c:1585:5: warning: "IF_64BIT_DMA_IS_POSSIBLE" is not defined
drivers/block/sx8.c:1604:5: warning: "IF_64BIT_DMA_IS_POSSIBLE" is not defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/drivers/block/sx8.c.old   2005-07-22 
18:13:45.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/block/sx8.c   2005-07-22 
18:14:05.0 +0200
@@ -1582,7 +1582,7 @@
if (rc)
goto err_out;
 
-#if IF_64BIT_DMA_IS_POSSIBLE /* g... */
+#ifdef IF_64BIT_DMA_IS_POSSIBLE /* g... */
rc = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
if (!rc) {
rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
@@ -1601,7 +1601,7 @@
goto err_out_regions;
}
pci_dac = 0;
-#if IF_64BIT_DMA_IS_POSSIBLE /* g... */
+#ifdef IF_64BIT_DMA_IS_POSSIBLE /* g... */
}
 #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/

RE: Kernel cached memory

[John Pearson]

Wouldn't having (practically) all your memory used for cache slow down
starting a new program? First it would have to free up that space, and then
put stuff in that space, taking potentially twice as long. I think there
should be a system call for freeing cached memory, for those that do want to
do it.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Erik Mouw
Sent: Friday, July 22, 2005 5:58 AM
To: Ashley
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel cached memory


On Fri, Jul 22, 2005 at 05:46:58PM +0800, Ashley wrote:
>I've a server with 2 Operton 64bit CPU and 12G memory, and this server
> is used to run  applications which will comsume huge memory,
> the problem is: when this aplications exits,  the free memory of the
server
> is still very low(accroding to the output of "top"), and
> from the output of command "free", I can see that many GB memory was
cached
> by kernel. Does anyone know how to free the kernel cached
> memory? thanks in advance.

Free memory is bad, it means the memory doesn't have a proper use.
Cached memory will be freed automatically when the kernel needs memory
for other (more important) things.


Erik

--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
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/

[2.6 patch] drivers/ieee1394/sbp2.c: fix warnings with -Wundef

[Adrian Bunk]

This patch fixes the following warnings with -Wundef:

<--  snip  -->

...
  CC  drivers/ieee1394/sbp2.o
drivers/ieee1394/sbp2.c:202:5: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not 
defined
drivers/ieee1394/sbp2.c:207:7: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not 
defined
drivers/ieee1394/sbp2.c:2053:6: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not 
defined
drivers/ieee1394/sbp2.c:2623:5: warning: "CONFIG_IEEE1394_SBP2_DEBUG" is not 
defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/drivers/ieee1394/sbp2.c.old   2005-07-22 
18:19:38.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/ieee1394/sbp2.c   2005-07-22 
18:20:32.0 +0200
@@ -171,10 +171,11 @@
 
 /* #define CONFIG_IEEE1394_SBP2_DEBUG_ORBS */
 /* #define CONFIG_IEEE1394_SBP2_DEBUG_DMA */
-/* #define CONFIG_IEEE1394_SBP2_DEBUG 1 */
-/* #define CONFIG_IEEE1394_SBP2_DEBUG 2 */
 /* #define CONFIG_IEEE1394_SBP2_PACKET_DUMP */
 
+/* CONFIG_IEEE1394_SBP2_DEBUG: 0-2 */
+#define CONFIG_IEEE1394_SBP2_DEBUG 0
+
 #ifdef CONFIG_IEEE1394_SBP2_DEBUG_ORBS
 #define SBP2_ORB_DEBUG(fmt, args...)   HPSB_ERR("sbp2(%s): "fmt, __FUNCTION__, 
## args)
 static u32 global_outstanding_command_orbs = 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/

[2.6 patch] drivers/char/rio/: fix warnings with -Wundef

[Adrian Bunk]

This patch fixes the following warnings with -Wundef:

<--  snip  -->

...
  CC  drivers/char/rio/rioboot.o
drivers/char/rio/rioboot.c:905:5: warning: "NEED_TO_FIX" is not defined
drivers/char/rio/rioboot.c:921:5: warning: "NEED_TO_FIX" is not defined
drivers/char/rio/rioboot.c:1146:5: warning: "NEED_TO_FIX" is not defined
drivers/char/rio/rioboot.c:1162:5: warning: "NEED_TO_FIX" is not defined
drivers/char/rio/rioboot.c:1172:5: warning: "NEED_TO_FIX" is not defined
drivers/char/rio/rioboot.c:1191:5: warning: "NEED_TO_FIX" is not defined
...
  CC  drivers/char/rio/rioroute.o
drivers/char/rio/rioroute.c:1026:5: warning: "NEED_TO_FIX_THIS" is not defined
  CC  drivers/char/rio/riotable.o
...
drivers/char/rio/riotable.c:774:5: warning: "NEED_TO_FIX" is not defined
...

<--  snip  -->


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

---

 drivers/char/rio/rioboot.c  |   12 ++--
 drivers/char/rio/rioroute.c |2 +-
 drivers/char/rio/riotable.c |2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

--- linux-2.6.13-rc3-mm1-full/drivers/char/rio/rioboot.c.old2005-07-22 
18:18:07.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/char/rio/rioboot.c2005-07-22 
18:47:35.0 +0200
@@ -902,7 +902,7 @@
   (HostP->Mapping[entry].RtaUniqueNum==RtaUniq))
{
HostP->Mapping[entry].Flags |= RTA_BOOTED|RTA_NEWBOOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry]);
 #endif
if ( (sysport=HostP->Mapping[entry].SysPort) != NO_PORT )
@@ -918,7 +918,7 @@
   {
entry2 = HostP->Mapping[entry].ID2 - 1;
HostP->Mapping[entry2].Flags |= RTA_BOOTED|RTA_NEWBOOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry2]);
 #endif
sysport = HostP->Mapping[entry2].SysPort;
@@ -1143,7 +1143,7 @@
CCOPY( MapP->Name, HostP->Mapping[entry].Name, MAX_NAME_LEN 
);
HostP->Mapping[entry].Flags =
 SLOT_IN_USE | RTA_BOOTED | RTA_NEWBOOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry]);
 #endif
RIOReMapPorts( p, HostP, >Mapping[entry] );
@@ -1159,7 +1159,7 @@
"This RTA has a tentative entry on another host - delete that entry (1)\n");
HostP->Mapping[entry].Flags =
 SLOT_TENTATIVE | RTA_BOOTED | RTA_NEWBOOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry]);
 #endif
}
@@ -1169,7 +1169,7 @@
{
HostP->Mapping[entry2].Flags = SLOT_IN_USE |
 RTA_BOOTED | RTA_NEWBOOT | RTA16_SECOND_SLOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry2]);
 #endif
HostP->Mapping[entry2].SysPort = MapP2->SysPort;
@@ -1188,7 +1188,7 @@
else
HostP->Mapping[entry2].Flags = SLOT_TENTATIVE |
 RTA_BOOTED | RTA_NEWBOOT | RTA16_SECOND_SLOT;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(HostP->svFlags[entry2]);
 #endif
bzero( (caddr_t)MapP2, sizeof(struct Map) );
--- linux-2.6.13-rc3-mm1-full/drivers/char/rio/rioroute.c.old   2005-07-22 
18:18:37.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/char/rio/rioroute.c   2005-07-22 
18:18:43.0 +0200
@@ -1023,7 +1023,7 @@
 if (link < LINKS_PER_UNIT)
return 1;
 
-#if NEED_TO_FIX_THIS
+#ifdef NEED_TO_FIX_THIS
 /* Ok so all the links are disconnected. But we may have only just
 ** made this slot tentative and not yet received a topology update.
 ** Lets check how long ago we made it tentative.
--- linux-2.6.13-rc3-mm1-full/drivers/char/rio/riotable.c.old   2005-07-22 
18:18:51.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/char/rio/riotable.c   2005-07-22 
18:18:55.0 +0200
@@ -771,7 +771,7 @@
if ((MapP->Flags & RTA16_SECOND_SLOT) == 0)
  CCOPY( MapP->Name, HostMapP->Name, MAX_NAME_LEN );
HostMapP->Flags = SLOT_IN_USE | RTA_BOOTED;
-#if NEED_TO_FIX
+#ifdef NEED_TO_FIX
RIO_SV_BROADCAST(p->RIOHosts[host].svFlags[MapP->ID-1]);
 #endif
if (MapP->Flags & RTA16_SECOND_SLOT)

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

[2.6 patch] drivers/net/ne.c: fix warning with -Wundef

[Adrian Bunk]

This patch fixes the following warning with -Wundef:

<--  snip  -->

...
  CC  drivers/net/ne.o
drivers/net/ne.c:134:7: warning: "CONFIG_PLAT_OAKS32R" is not defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/drivers/net/ne.c.old  2005-07-22 
18:24:32.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/net/ne.c  2005-07-22 18:24:50.0 
+0200
@@ -131,7 +131,7 @@
 
 #ifdef CONFIG_PLAT_MAPPI
 #  define DCR_VAL 0x4b
-#elif CONFIG_PLAT_OAKS32R
+#elif defined(CONFIG_PLAT_OAKS32R)
 #  define DCR_VAL 0x48
 #else
 #  define DCR_VAL 0x49

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

[2.6 patch] drivers/cdrom/mcdx.c: fix -Wundef warnings

[Adrian Bunk]

This patch fixes the following warnings with -Wundef:

<--  snip  -->

...
  CC  drivers/cdrom/mcdx.o
drivers/cdrom/mcdx.c:54:5: warning: "RCS" is not defined
...
drivers/cdrom/mcdx.c:709:5: warning: "FALLBACK" is not defined
drivers/cdrom/mcdx.c:1219:5: warning: "WE_KNOW_WHY" is not defined
drivers/cdrom/mcdx.c:1297:5: warning: "FALLBACK" is not defined
...

<--  snip  -->


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

---

 drivers/cdrom/mcdx.c |   11 +++
 1 files changed, 3 insertions(+), 8 deletions(-)

--- linux-2.6.13-rc3-mm1-full/drivers/cdrom/mcdx.c.old  2005-07-22 
18:14:36.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/cdrom/mcdx.c  2005-07-22 
18:15:29.0 +0200
@@ -51,11 +51,6 @@
  */
 
 
-#if RCS
-static const char *mcdx_c_version
-= "$Id: mcdx.c,v 1.21 1997/01/26 07:12:59 davem Exp $";
-#endif
-
 #include 
 
 #include 
@@ -706,7 +701,7 @@
xtrace(OPENCLOSE, "open() init irq generation\n");
if (-1 == mcdx_config(stuffp, 1))
return -EIO;
-#if FALLBACK
+#ifdef FALLBACK
/* Set the read speed */
xwarn("AAA %x AAA\n", stuffp->readcmd);
if (stuffp->readerrs)
@@ -1216,7 +1211,7 @@
}
 
 
-#if WE_KNOW_WHY
+#ifdef WE_KNOW_WHY
/* irq 11 -> channel register */
outb(0x50, stuffp->wreg_chn);
 #endif
@@ -1294,7 +1289,7 @@
 
ans = mcdx_xfer(stuffp, p, sector, nr_sectors);
return ans;
-#if FALLBACK
+#ifdef FALLBACK
if (-1 == ans)
stuffp->readerrs++;
else

-
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: Kernel doesn't free Cached Memory

[Alan Cox]

On Gwe, 2005-07-22 at 13:00 -0300, Vinicius wrote:
>I also read on the Linux-Kernel that the problem may be related to an 
> exhaustion of your kernels address space, I read that the hugemem-kernel 
> might be the solution to this case since it has 4GB for the kernel memory 
> plus 4GB for user process. 

If its x86-32 then only the hugemem kernel will even see the memory.
There are big problems with 32Gb+ on a 32bit processor because there is
so little memory usable at a time that even the page tables become
problematic. Thankfully all sane machines with that much ram are 64bit.

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

[-mm patch] include/net/ieee80211.h must #include

[Adrian Bunk]

-Wundef found an (although perhaps harmless) bug:

<--  snip  -->

...
  CC  net/ieee80211/ieee80211_crypt.o
In file included from net/ieee80211/ieee80211_crypt.c:21:
include/net/ieee80211.h:26:5: warning: "WIRELESS_EXT" is not defined
  CC  net/ieee80211/ieee80211_crypt_wep.o
In file included from net/ieee80211/ieee80211_crypt_wep.c:20:
include/net/ieee80211.h:26:5: warning: "WIRELESS_EXT" is not defined
  CC  net/ieee80211/ieee80211_crypt_ccmp.o
  CC  net/ieee80211/ieee80211_crypt_tkip.o
In file included from net/ieee80211/ieee80211_crypt_tkip.c:23:
include/net/ieee80211.h:26:5: warning: "WIRELESS_EXT" is not defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/include/net/ieee80211.h.old   2005-07-22 
18:37:57.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/net/ieee80211.h   2005-07-22 
18:38:10.0 +0200
@@ -22,6 +22,7 @@
 #define IEEE80211_H
 #include  /* ETH_ALEN */
 #include/* ARRAY_SIZE */
+#include 
 
 #if WIRELESS_EXT < 17
 #define IW_QUAL_QUAL_INVALID   0x10

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

[2.6 patch] drivers/isdn/hisax/l3dss1.c: fix warning with -Wundef

[Adrian Bunk]

This patch fixes the following warning with -Wundef:

<--  snip  -->

...
  CC  drivers/isdn/hisax/l3dss1.o
drivers/isdn/hisax/l3dss1.c:356:5: warning: "HISAX_DE_AOC" is not defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/drivers/isdn/hisax/l3dss1.c.old   2005-07-22 
18:20:59.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/isdn/hisax/l3dss1.c   2005-07-22 
18:21:42.0 +0200
@@ -353,7 +353,7 @@
 { l3dss1_dummy_invoke(st, cr, id, ident, p, 
nlen);
return;
  } 
-#if HISAX_DE_AOC
+#ifdef HISAX_DE_AOC
{
 
 #define FOO1(s,a,b) \

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

[2.6 patch] ftape: fix warnings with -Wundef

[Adrian Bunk]

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

--- linux-2.6.13-rc3-mm1-full/include/linux/ftape.h.old 2005-07-22 
18:17:18.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/ftape.h 2005-07-22 
18:17:41.0 +0200
@@ -165,7 +165,7 @@
 #  undef  CONFIG_FT_FDC_DMA
 #  define CONFIG_FT_FDC_DMA 2
 # endif
-#elif CONFIG_FT_ALT_FDC == 1  /* CONFIG_FT_MACH2 */
+#elif defined(CONFIG_FT_ALT_FDC)  /* CONFIG_FT_MACH2 */
 # if CONFIG_FT_FDC_BASE == 0
 #  undef  CONFIG_FT_FDC_BASE
 #  define CONFIG_FT_FDC_BASE 0x370

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

[2.6 patch] drivers/char/drm/drm_pci.c: fix -Wundef warnings

[Adrian Bunk]

This patch fixes the following warnings with -Wundef:

<--  snip  -->

...
  CC  drivers/char/drm/drm_pci.o
drivers/char/drm/drm_pci.c:53:5: warning: "DRM_DEBUG_MEMORY" is not defined
drivers/char/drm/drm_pci.c:84:5: warning: "DRM_DEBUG_MEMORY" is not defined
drivers/char/drm/drm_pci.c:119:5: warning: "DRM_DEBUG_MEMORY" is not defined
drivers/char/drm/drm_pci.c:126:5: warning: "DRM_DEBUG_MEMORY" is not defined
drivers/char/drm/drm_pci.c:134:5: warning: "DRM_DEBUG_MEMORY" is not defined
...

<--  snip  -->


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

---

 drivers/char/drm/drm_pci.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

--- linux-2.6.13-rc3-mm1-full/drivers/char/drm/drm_pci.c.old2005-07-22 
18:16:02.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/char/drm/drm_pci.c2005-07-22 
18:16:24.0 +0200
@@ -50,7 +50,7 @@
dma_addr_t maxaddr)
 {
drm_dma_handle_t *dmah;
-#if DRM_DEBUG_MEMORY
+#ifdef DRM_DEBUG_MEMORY
int area = DRM_MEM_DMA;
 
spin_lock(_mem_lock);
@@ -81,7 +81,7 @@
dmah->size = size;
dmah->vaddr = pci_alloc_consistent(dev->pdev, size, >busaddr);
 
-#if DRM_DEBUG_MEMORY
+#ifdef DRM_DEBUG_MEMORY
if (dmah->vaddr == NULL) {
spin_lock(_mem_lock);
++drm_mem_stats[area].fail_count;
@@ -116,14 +116,14 @@
 void
 __drm_pci_free(drm_device_t * dev, drm_dma_handle_t *dmah)
 {
-#if DRM_DEBUG_MEMORY
+#ifdef DRM_DEBUG_MEMORY
int area = DRM_MEM_DMA;
int alloc_count;
int free_count;
 #endif
 
if (!dmah->vaddr) {
-#if DRM_DEBUG_MEMORY
+#ifdef DRM_DEBUG_MEMORY
DRM_MEM_ERROR(area, "Attempt to free address 0\n");
 #endif
} else {
@@ -131,7 +131,7 @@
dmah->busaddr);
}
 
-#if DRM_DEBUG_MEMORY
+#ifdef DRM_DEBUG_MEMORY
spin_lock(_mem_lock);
free_count = ++drm_mem_stats[area].free_count;
alloc_count = drm_mem_stats[area].succeed_count;

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

Re: select() efficiency

[bert hubert]

On Fri, Jul 22, 2005 at 04:18:46PM -0500, Davy Durham wrote:
> Please forgive and redirect me if this is not the right place to ask 
> this question:
> 
> I'm looking to write a sort of messaging system that would take input 
> from any number of entities that "register" with it.. it would then 
> route the messages to outputs and so forth..

Look at epoll, or libevent, which uses epoll to be quick in this scenario.


-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
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: Why build empty object files in drivers/media?

[Olaf Dietsche]

Sam Ravnborg <[EMAIL PROTECTED]> writes:

> +obj-$(CONFIG_VIDEO_DEV) := video/
> +obj-$(CONFIG_VIDEO_DEV) := radio/

  s/VIDEO/RADIO/

Regards, Olaf.
-
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/

select() efficiency

[Davy Durham]

Please forgive and redirect me if this is not the right place to ask 
this question:


I'm looking to write a sort of messaging system that would take input 
from any number of entities that "register" with it.. it would then 
route the messages to outputs and so forth..


I'm guessing that the messaging system would be a single process on the 
machine..


So, I'm considering making the means of input to the system be a unix 
socket.  An entity would connect to the socket as it's means of 
inputting messages into the system. 

However, lets suppose that 1000+ entities connect to that socket.. this 
would require the message system's loop to be adding 1000+ file 
descriptures to an fd_set and call select() every time it loops around 
to check for any messages.


So, my question is: how efficient would things be, doing selects() very 
often on 1000+ file descriptors?  I'm not aware of max size for an 
fd_set.. (I do know that NT is limited to 64 handles.. but that's really 
beside the point unless I look at porting someday)


Should I go another route?

The system is meant to rapidly route messages ASAP.. so it would be a 
bad idea to say write them to a file and poll the file or something like 
that...


Another thought was to use a system-wide mutex and write to a named 
pipe, but the socket method seems more appealing to me in design... and 
I didn't know if it was pretty much equivalent either way since either I 
will do the work of dealing with 1000+ things or the kernel will.


Thanks,
 Davy
-
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/

[-mm patch] kernel/ckrm/rbce/rbce_core.c: fix -Wundef warning

[Adrian Bunk]

On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc2-mm2:
>...
> +ckrm-rule-based-classification-engine-full-ce.patch
>...
>  Class-based kernel resource management
>...

This patch fixes the following warning with -Wundef:

<--  snip  -->

...
  CC  kernel/ckrm/rbce/rbce_core.o
kernel/ckrm/rbce/rbce_core.c:323:5: warning: "__NOT_YET__" is not defined
...

<--  snip  -->


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

--- linux-2.6.13-rc3-mm1-full/kernel/ckrm/rbce/rbce_core.c.old  2005-07-22 
18:04:28.0 +0200
+++ linux-2.6.13-rc3-mm1-full/kernel/ckrm/rbce/rbce_core.c  2005-07-22 
18:04:36.0 +0200
@@ -320,7 +320,7 @@
 
case RBCE_RULE_CMD_PATH:
case RBCE_RULE_CMD:
-#if __NOT_YET__
+#ifdef __NOT_YET__
if (!*filename) {   /* get this once */
if (((*filename =
  kmalloc(NAME_MAX,

-
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: kernel optimization

[christos gentsis]

Adrian Bunk wrote:


On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:

 


hello
   



Hi Chris,

 

i would like to ask if it possible to change the optimization of the 
kernel from -O2 to -O3 :D, how can i do that? if i change it to the top 
level Makefile does it change to all the Makefiles?
   



search for the line with
 CFLAGS  += -O2
and change this to -O3.

This works for most Makefile's except for the one's that manually
set -Os.

 

And let's say that i change it... does this generate any problems with 
the space that the kernel will take? (the kernel will be much larger)
   



It's completely untested.
And since it's larger, it's also slower.

 


Thanks
Chris
   



cu
Adrian

 

so if i want to play with and see what happens i have to change it 
manually in each make file... good i may create a kernel like that to 
see what will happens (just for test) ;)


thanks
Chris

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

[2.6 patch] drivers/net/8139too.c: rework the debug levels

[Adrian Bunk]

I started looking at this driver after seeing the following warnings 
with -Wundef:

<--  snip  -->

...
  CC  drivers/net/8139too.o
drivers/net/8139too.c:1961:5: warning: "RTL8139_DEBUG" is not defined
drivers/net/8139too.c:2047:5: warning: "RTL8139_DEBUG" is not defined
...

<--  snip  -->


Looking at this driver, I wondered why there were two different 
#define's controlling the debug output of the driver.

This patch consolidates this to one debug level, and the default
setting "1" results in exactly the same 8139too.o as with the old 
defaults.

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

---

 drivers/net/8139too.c |   22 ++
 1 files changed, 10 insertions(+), 12 deletions(-)

--- linux-2.6.13-rc3-mm1-full/drivers/net/8139too.c.old 2005-07-22 
18:25:11.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/net/8139too.c 2005-07-22 
18:32:17.0 +0200
@@ -85,7 +85,8 @@
Submitting bug reports:
 
"rtl8139-diag -mmmaaavvveefN" output
-   enable RTL8139_DEBUG below, and look at 'dmesg' or kernel log
+   set RTL8139_DEBUG to a higher debug level below,
+   and look at 'dmesg' or kernel log
 
 */
 
@@ -126,21 +127,18 @@
 #define USE_IO_OPS 1
 #endif
 
-/* define to 1 to enable copious debugging info */
-#undef RTL8139_DEBUG
+/* debug levels: 0-4 */
+#define RTL8139_DEBUG 1
 
-/* define to 1 to disable lightweight runtime debugging checks */
-#undef RTL8139_NDEBUG
 
-
-#ifdef RTL8139_DEBUG
+#if RTL8139_DEBUG > 1
 /* note: prints function name for you */
 #  define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , 
## args)
 #else
 #  define DPRINTK(fmt, args...)
 #endif
 
-#ifdef RTL8139_NDEBUG
+#if RTL8139_DEBUG == 0
 #  define assert(expr) do {} while (0)
 #else
 #  define assert(expr) \
@@ -1794,13 +1792,13 @@
tx_left--;
}
 
-#ifndef RTL8139_NDEBUG
+#if RTL8139_DEBUG > 0
if (tp->cur_tx - dirty_tx > NUM_TX_DESC) {
printk (KERN_ERR "%s: Out-of-sync dirty pointer, %ld vs. 
%ld.\n",
dev->name, dirty_tx, tp->cur_tx);
dirty_tx += NUM_TX_DESC;
}
-#endif /* RTL8139_NDEBUG */
+#endif /* RTL8139_DEBUG > 0 */
 
/* only wake the queue if we did work, and the queue is stopped */
if (tp->dirty_tx != dirty_tx) {
@@ -1958,7 +1956,7 @@
printk(KERN_DEBUG "%s:  rtl8139_rx() status %4.4x, size 
%4.4x,"
" cur %4.4x.\n", dev->name, rx_status,
 rx_size, cur_rx);
-#if RTL8139_DEBUG > 2
+#if RTL8139_DEBUG > 3
{
int i;
DPRINTK ("%s: Frame contents ", dev->name);
@@ -2044,7 +2042,7 @@
if (unlikely(!received || rx_size == 0xfff0))
rtl8139_isr_ack(tp);
 
-#if RTL8139_DEBUG > 1
+#if RTL8139_DEBUG > 2
DPRINTK ("%s: Done rtl8139_rx(), current %4.4x BufAddr %4.4x,"
 " free to %4.4x, Cmd %2.2x.\n", dev->name, cur_rx,
 RTL_R16 (RxBufAddr),

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

[2.6 patch] remove the obsolete SCSI qlogicisp driver

[Adrian Bunk]

The SCSI qlogicisp driver is both marked BROKEN and superseded by the 
qla1280 driver.

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

---

Due to it's size, the patch is attached compressed.

 Documentation/scsi/00-INDEX  |2 
 Documentation/scsi/qlogicfas.txt |3 
 Documentation/scsi/qlogicisp.txt |   30 
 drivers/scsi/Kconfig |   29 
 drivers/scsi/Makefile|1 
 drivers/scsi/qlogicisp.c | 1934 -
 drivers/scsi/qlogicisp_asm.c | 2034 ---
 7 files changed, 1 insertion(+), 4032 deletions(-)




patch-remove-qlogicisp.gz
Description: Binary data

Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

[vamsi krishna]

Really appreciate that, is roland mcgrath listening? what's his email ID?

On 7/23/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> 
> On Fri, 22 Jul 2005, vamsi krishna wrote:
> 
> > Hi,
> >
> >> It doesn't. The 32-bit machines never show 64 bit words in
> >> /proc/NN/maps. They don't "know" how.
> >>
> >> b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0
> >> b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0
> >> bffe1000-bfff6000 rw-p bffe1000 00:00 0  [stack]
> >> e000-f000 ---p  00:00 0  [vdso]
> >>  32 bits
> >
> > hello john can you tell me what is [vdso], does it have any content
> > related file descriptor table it seems that the if I dont save this
> > segment during checkpointing,  the file open descriptors (i.e FILE *)
> > seems to have null after restoration.
> >
> > Sincerely appreciate your inputs.
> >
> > Cheers!
> > Vamsi
> >
> 
> #include 
> 
> int main()
> {
>  long *foo = (long *)0xe000;
>  printf("%08x\n", foo[0]);
>  printf("%08x\n", foo[1]);
>  printf("%08x\n", foo[2]);
>  printf("%08x\n", foo[3]);
>  printf("%08x\n", foo[4]);
>  printf("%s\n", (char *)foo);
> 
> }
> 
> Seems to be readable and starts with 'ELF'. It's something
> the the 'C' runtime may library use to make syscalls to the
> kernel. Older libraries used interrupt 0x80, newer ones
> may use this. Roland McGrath has made patches to this
> segment so maybe he knows.
> 
> 
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> I apologize for the following. I tried to kill it with the above dot :
> 
> 
> The information transmitted in this message is confidential and may be 
> privileged.  Any review, retransmission, dissemination, or other use of this 
> information by persons or entities other than the intended recipient is 
> prohibited.  If you are not the intended recipient, please notify Analogic 
> Corporation immediately - by replying to this message or by sending an email 
> to [EMAIL PROTECTED] - and destroy all copies of this information, including 
> any attachments, without reading or disclosing them.
> 
> Thank you.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: a 15 GB file on tmpfs

[Stefan Smietanowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bernd Eckenfels wrote:
> On Fri, Jul 22, 2005 at 01:00:18PM +0200, Stefan Smietanowski wrote:
> 
>>>You cant have 16GB of Memory with 32bit CPUs.
>>
>>PAE
>>CONFIG_HIGMEM64G
>>Supports a 36bit address space, which Xeons do support.
> 
> 
> Yes right, I was just not aware recent hardware (still) supports that. I
> mean even mit 2MB modules most of them are specified only to 8GB. I would
> consider buying such a system quite foolish. All of the HP servers with 12GB
> and more seem to support EM64T. Do you know vendors who ship non-EM64T
> servers with more than 16GB?

http://www.intel.com/products/processor/xeon/index.htm

Shows that the lowest speed Xeon with EM64T is 2.83GHz.

http://commerce.euro.dell.com/dellstore/config/frameset.asp?c=607=3410=62417=gbp=ukbsdt1=ukbsdpedge=d=etstore=en=ukbsd=ukbsd

Shows a system taking 1-4 of those processors at 2.0, 2.2, 2.7 and
3.0GHz, making them 32bit only.

Memory you can configure is from 1GiB (4x256MiB) to 32GiB (16x2GiB).

If I'd buy a server I wouldn't buy one of those however, I'm just
answering the question.

Disclaimer: I do not have anything to do with either of the above
mentioned vendors. I just looked up the first vendor that came into
my head.

// Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFC4WDjBrn2kJu9P78RAn9RAJ9wRffW5VB0WbRgRBNjfN9+k3XMvgCgtWAO
mu8p8nj8iIpNIkuYiMkiTuI=
=9kQz
-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: itimer oddness in 2.6.12

[Tom Marshall]

On Fri, Jul 22, 2005 at 08:21:25PM +0100, Paulo Marques wrote:
> Tom Marshall wrote:
> >The patch to fix "setitimer timer expires too early" is causing issues for
> >the Helix server.  We have a timer processs that updates the server's
> >timestamp on an itimer and it expects the signal to be delivered at roughly
> >the interval retrieved from getitimer.  This is very consistent on every
> >platform, including Linux up to 2.6.11, but breaks on 2.6.12.  On 2.6.12,
> >setting the itimer to 10ms and retrieving the actual interval from 
> >getitimer
> >reports 10.998ms, but the timer interrupts are consistently delivered at
> >roughly 11.998ms.  
> 
> Unfortunately, this is not so clear cut as it seems :(

Yes, I am sure that it is not a simple problem.  I am not a kernel developer
but I imagine that issues such as NTP adjustments would complicate this
issue.  I must also admit that I am not intimately familiar with the POSIX
spec regarding itimers.

Our current code does a setitimer followed by getitimer, then uses the
actual interval retrieved by getitimer to set a global timer delta.  On each
timer signal, it updates the notion of the current time by the timer delta. 
As mentioned, this works on every other platform (Solaris, BSD, HPUX, AIX,
DGUX, IRIX, Tru64, and Linux up to 2.6.11) but breaks on 2.6.12.

This is not an insurmountable problem for userspace.  It can be easily
solved by using gettimeofday in the timer interrupt instead of adding the
delta to the current time blindly.  No big deal.  I just wanted to point
this issue out and ensure that (1) it was a known issue, and (2) it is the
direction that the Linux kernel intends to take.  If so, no big deal and we
can modify the timer code to take that into account.

-- 
Apathy Club meeting this Friday.  If you want to come, you're not invited.


signature.asc
Description: Digital signature

RE: Memory Management

[Roger Heflin]

I have seen RH3.0 crash on 32GB systems because it has too
much memory tied up in write cache.  It required update 2 
(this was a while ago) and a change of a parameter in /proc
to prevent the crash, it was because of a overagressive
write caching change RH implemented in the kernel resulted
in the crash.  This crash was an OOM related crash.  To
duplicate the bug, you booted the machine and ran a dd
to create a very large file filling the disk.

We did test and did determine that it did not appear to have
the issue if you had less than 28GB of ram, this was on an
itanium machine, so I don't know if it occurs on other arches,
and if it occurs at the same memory limits on the other arches
either.

Roger

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Márcio Oliveira
> Sent: Friday, July 22, 2005 2:42 PM
> To: Neil Horman
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
> Subject: Re: Memory Management
> 
> Neil Horman wrote:
> 
> >On Fri, Jul 22, 2005 at 11:32:52AM -0300, Márcio Oliveira wrote:
> >  
> >
> >>Neil Horman wrote:
> >>
> >>
> >>
> >>>On Thu, Jul 21, 2005 at 10:40:54AM -0300, Márcio Oliveira wrote:
> >>>
> >>>
> >>>  
> >>>
> >http://people.redhat.com/nhorman/papers/rhel3_vm.pdf
> >I wrote this with norm awhile back.  It may help you out.
> >Regards
> >Neil
> >
> >
> >
> >
> >  
> >
> Neil,
> 
> Thanks.~10-12GB of total RAM (16GB) are
> 
> How can Proc virtual memory parameters like 
> inactive_clean_percent, 
> overcommit_memory, overcommit_ratio and page_cache help 
> me to solve 
> / reduce Out Of Memory conditions on servers with 16GB 
> RAM and lots 
> of GB swap?
> 
>   
> 
> 
> 
> >>>I wouldn't touch memory overcommit if you are already 
> seeing out of 
> >>>memory issues.  If you are using lots of pagecache, I 
> would suggest 
> >>>increasing inactive_clean percent, reducing the 
> pagecahce.max value, 
> >>>and modifying the bdflush parameters in the above document 
> such that 
> >>>bdflush runs sooner, more often, and does more work per 
> iteration.  
> >>>This will help you move data in pagecache back to disk more 
> >>>aggressively so that memory will be available for other purposes, 
> >>>like heap allocations. Also if you're using a Red Hat 
> kernel and you 
> >>>have 16GB of ram in your system, you're a good candidate for the 
> >>>hugemem kernel.  Rather than a straightforward out of memory 
> >>>condition, you may be seeing a exhaustion of your kernels address 
> >>>space (check LowFree in /proc/meminfo).  In this even the hugemem 
> >>>kernel will help you in that it increases your Low Memory address 
> >>>space from 1GB to 4GB, preventing some OOM conditions.
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>
> Kernel does not free cached memory (~10-12GB of total RAM 
> - 16GB). Is 
> there some way to force the kernel to free cached memory?
> 
>   
> 
> 
> 
> >>>Cached memory is freed on demand.  Just because its listed 
> under the 
> >>>cached line
> >>>below doesn't mean it can't be freed and used for another 
> purpose.  
> >>>Implement
> >>>the tunings above, and your situation should improve.
> >>>
> >>>Regards
> >>>Neil
> >>>
> >>>
> >>>
> >>>  
> >>>
> /proc/meminfo:
> 
>    total:used:free:  shared: buffers:  cached:
> Mem:16603488256 1652632 801546240 
> 70651904 13194563584
> Swap:   17174257664 11771904 17162485760
> MemTotal: 16214344 kB
> MemFree: 78276 kB
> Buffers: 68996 kB
> Cached:   12874808 kB
> 
> Thanks to all.
> 
> Marcio.
>   
> 
> 
> 
> >>Neil,
> >>
> >>  Thanks for the answers!
> >>
> >>The following lines are the Out Of Memory log:
> >>
> >>Jul 20 13:45:44 server kernel: Out of Memory: Killed 
> process 23716 (oracle).
> >>Jul 20 13:45:44 server kernel: Fixed up OOM kill of mm-less task
> >>Jul 20 13:45:45 server su(pam_unix)[3848]: session closed 
> for user root
> >>Jul 20 13:45:48 server kernel: Mem-info:
> >>Jul 20 13:45:48 server kernel: Zone:DMA freepages:  1884 min: 0 
> >>low: 0 high: 0
> >>Jul 20 13:45:48 server kernel: Zone:Normal freepages:  1084 
> min:  1279 
> >>low:  4544 high:  6304
> >>Jul 20 13:45:48 server kernel: Zone:HighMem 
> freepages:386679 min:   255 
> >>low: 61952 high: 92928
> >>Jul 20 13:45:48 server kernel: Free pages:  389647 
> (386679 HighMem)
> >>Jul 20 13:45:48 server kernel: ( Active: 2259787/488777, 
> >>inactive_laundry: 244282, inactive_clean: 244366, free: 389647 )
> >>Jul 20 13:45:48 server kernel:   aa:0 ac:0 id:0 il:0 ic:0 fr:1884
> >>Jul 20 13:45:48 server kernel:   aa:1620 ac:1801 id:231 
> il:15 ic:0 fr:1085
> >>Jul 20 13:45:48 server kernel:   aa:1099230 ac:1157136 id:488536 
> >>il:244277 ic:244366 fr:386679
> >>Jul 

Re: Merging relayfs?

[Tom Zanussi]

Tom Zanussi writes:
 > 
 > OK, if we got rid of the padding counts and commit counts and let the
 > client manage those, we can simplify the buffer switch slow path and
 > make the API simpler in the process.  Here's a first proposal for
 > doing that - I won't know until I actually do it what snags I may run
 > into, but if this looks like the right direction to go, I'll go ahead
 > with it...
 > 

And here's a patch to update the Documentation...


diff -urpN -X dontdiff 
linux-2.6.13-rc3-mm1/Documentation/filesystems/relayfs.txt 
linux-2.6.13-rc3-mm1-cur/Documentation/filesystems/relayfs.txt
--- linux-2.6.13-rc3-mm1/Documentation/filesystems/relayfs.txt  2005-07-16 
11:47:32.0 -0500
+++ linux-2.6.13-rc3-mm1-cur/Documentation/filesystems/relayfs.txt  
2005-07-23 12:50:46.0 -0500
@@ -23,6 +23,47 @@ This document provides an overview of th
 the function parameters are documented along with the functions in the
 filesystem code - please see that for details.
 
+Semantics
+=
+
+Each relayfs channel has one buffer per CPU, each buffer has one or
+more sub-buffers. Messages are written to the first sub-buffer until
+it is too full to contain a new message, in which case it it is
+written to the next (if available).  Messages are never split across
+sub-buffers.  At this point, userspace can be notified so it empties
+the first sub-buffer, while the kernel continues writing to the next.
+
+When notified that a sub-buffer is full, the kernel knows how many
+bytes of it are padding i.e. unused.  Userspace can use this knowledge
+to copy only valid data.
+
+After copying it, userspace can notify the kernel that a sub-buffer
+has been consumed.
+
+relayfs can operate in a mode where it will overwrite data not yet
+collected by userspace, and not wait for it to consume it.
+
+relayfs itself does not provide for communication of such data between
+userspace and kernel, allowing the kernel side to remain simple and not
+impose a single interface on userspace. It does provide a separate
+helper though, described below.
+
+klog, relay-app & librelay
+==
+
+relayfs itself is ready to use, but to make things easier, two
+additional systems are provided. klog is a simple wrapper to make
+sending data to a channel simpler, regardless of whether a channel to
+write to exists or not.  relay-app is the kernel counterpart of
+userspace librelay.c, combined these two files provide glue to easily
+stream data, without having to bother with housekeeping.
+
+It is possible to use relayfs without relay-app & librelay, but you'll
+have to implement communication between userspace and kernel, allowing
+both to convey the state of buffers (full, empty, amount of padding).
+
+klog, relay-app and librelay can be found in the relay-apps tarball on
+http://relayfs.sourceforge.net
 
 The relayfs user space API
 ==
@@ -34,7 +75,8 @@ available and some comments regarding th
 open()  enables user to open an _existing_ buffer.
 
 mmap()  results in channel buffer being mapped into the caller's
-memory space.
+memory space. Note that you can't do a partial mmap - you must
+map the entire file, which is NRBUF * SUBBUFSIZE. 
 
 poll()  POLLIN/POLLRDNORM/POLLERR supported.  User applications are
 notified when sub-buffer boundaries are crossed.
@@ -63,13 +105,15 @@ Here's a summary of the API relayfs prov
   channel management functions:
 
 relay_open(base_filename, parent, subbuf_size, n_subbufs,
-   overwrite, callbacks)
+   callbacks)
 relay_close(chan)
 relay_flush(chan)
 relay_reset(chan)
 relayfs_create_dir(name, parent)
 relayfs_remove_dir(dentry)
-relay_commit(buf, reserved, count)
+
+  channel management typically called on instigation of userspace:
+
 relay_subbufs_consumed(chan, cpu, subbufs_consumed)
 
   write functions:
@@ -77,19 +121,22 @@ Here's a summary of the API relayfs prov
 relay_write(chan, data, length)
 __relay_write(chan, data, length)
 relay_reserve(chan, length)
+__relay_reserve(buf, length)
 
   callbacks:
 
-subbuf_start(buf, subbuf, prev_subbuf_idx, prev_subbuf)
-deliver(buf, subbuf_idx, subbuf)
+subbuf_start(buf, subbuf, prev_subbuf, prev_padding)
 buf_mapped(buf, filp)
 buf_unmapped(buf, filp)
-buf_full(buf, subbuf_idx)
 
+  helper functions:
+
+relay_buf_full(buf)
+subbuf_start_reserve(buf, length)
 
-A relayfs channel is made of up one or more per-cpu channel buffers,
-each implemented as a circular buffer subdivided into one or more
-sub-buffers.
+
+Creating a channel
+--
 
 relay_open() is used to create a channel, along with its per-cpu
 channel buffers.  Each channel buffer will have an associated file
@@ -117,30 +164,106 @@ though, it's safe to assume that having 
 idea - you're guaranteed to either overwrite data or lose events
 depending on the channel mode being used.
 
-relayfs 

Re: Merging relayfs?

[Tom Zanussi]

Tom Zanussi writes:
 > 
 > OK, if we got rid of the padding counts and commit counts and let the
 > client manage those, we can simplify the buffer switch slow path and
 > make the API simpler in the process.  Here's a first proposal for
 > doing that - I won't know until I actually do it what snags I may run
 > into, but if this looks like the right direction to go, I'll go ahead
 > with it...
 > 

Here's a preliminary patch that does this cleanup.  It ends up being a
nice little simplification of the API and the buffer switch path.
Despite the size of the patch, the changes aren't that significant and
they don't reduce the functionality at all - I've tested using an
updated version of the relay-apps examples - those are still in flux
at the moment, but if anyone wants to see them now, I'll clean them up
and make them available.  I have tested that things basically work,
but I still need to do more testing; I'm posting now just in case
anyone disagrees with the changes.

I'll also be posting an update to the documentation shortly.

Here are the changes made by this patch:

- changed unsigned to unsigned int, and also changed several uses of
int to unsigned int where it made sense
- removed the padding counts and commit counts
- changed the subbuf_start() callback to add a prev_padding param, and
return a boolean value to indicate whether or not the buffer switch
should occur
- added a subbuf_start_reserve() helper function
- removed the deliver() callback
- removed the relay_commit() function
- removed the buf_full() callback
- added __relay_reserve(), which is used by relay_reserve() but allows
a client that already has a buffer pointer to use that instead

Tom


diff -urpN -X dontdiff linux-2.6.13-rc3-mm1/fs/relayfs/buffers.c 
linux-2.6.13-rc3-mm1-cur/fs/relayfs/buffers.c
--- linux-2.6.13-rc3-mm1/fs/relayfs/buffers.c   2005-07-16 11:47:34.0 
-0500
+++ linux-2.6.13-rc3-mm1-cur/fs/relayfs/buffers.c   2005-07-22 
01:10:21.0 -0500
@@ -95,7 +95,7 @@ int relay_mmap_buf(struct rchan_buf *buf
 static void *relay_alloc_buf(struct rchan_buf *buf, unsigned long size)
 {
void *mem;
-   int i, j, n_pages;
+   unsigned int i, j, n_pages;
 
size = PAGE_ALIGN(size);
n_pages = size >> PAGE_SHIFT;
@@ -137,27 +137,15 @@ struct rchan_buf *relay_create_buf(struc
if (!buf)
return NULL;
 
-   buf->padding = kmalloc(chan->n_subbufs * sizeof(unsigned *), 
GFP_KERNEL);
-   if (!buf->padding)
-   goto free_buf;
-
-   buf->commit = kmalloc(chan->n_subbufs * sizeof(unsigned *), GFP_KERNEL);
-   if (!buf->commit)
-   goto free_buf;
-
buf->start = relay_alloc_buf(buf, chan->alloc_size);
-   if (!buf->start)
-   goto free_buf;
-
+   if (!buf->start) {
+   kfree(buf);
+   return NULL;
+   }
+   
buf->chan = chan;
kref_get(>chan->kref);
return buf;
-
-free_buf:
-   kfree(buf->commit);
-   kfree(buf->padding);
-   kfree(buf);
-   return NULL;
 }
 
 /**
@@ -167,7 +155,7 @@ free_buf:
 void relay_destroy_buf(struct rchan_buf *buf)
 {
struct rchan *chan = buf->chan;
-   int i;
+   unsigned int i;
 
if (likely(buf->start)) {
vunmap(buf->start);
@@ -175,8 +163,6 @@ void relay_destroy_buf(struct rchan_buf 
__free_page(buf->page_array[i]);
kfree(buf->page_array);
}
-   kfree(buf->padding);
-   kfree(buf->commit);
kfree(buf);
kref_put(>kref, relay_destroy_channel);
 }
diff -urpN -X dontdiff linux-2.6.13-rc3-mm1/fs/relayfs/relay.c 
linux-2.6.13-rc3-mm1-cur/fs/relayfs/relay.c
--- linux-2.6.13-rc3-mm1/fs/relayfs/relay.c 2005-07-16 11:47:34.0 
-0500
+++ linux-2.6.13-rc3-mm1-cur/fs/relayfs/relay.c 2005-07-23 09:27:40.0 
-0500
@@ -26,10 +26,7 @@
  */
 int relay_buf_empty(struct rchan_buf *buf)
 {
-   int produced = atomic_read(>subbufs_produced);
-   int consumed = atomic_read(>subbufs_consumed);
-
-   return (produced - consumed) ? 0 : 1;
+   return (buf->subbufs_produced - buf->subbufs_consumed) ? 0 : 1;
 }
 
 /**
@@ -38,17 +35,10 @@ int relay_buf_empty(struct rchan_buf *bu
  *
  * Returns 1 if the buffer is full, 0 otherwise.
  */
-static inline int relay_buf_full(struct rchan_buf *buf)
+int relay_buf_full(struct rchan_buf *buf)
 {
-   int produced, consumed;
-
-   if (buf->chan->overwrite)
-   return 0;
-
-   produced = atomic_read(>subbufs_produced);
-   consumed = atomic_read(>subbufs_consumed);
-
-   return (produced - consumed > buf->chan->n_subbufs - 1) ? 1 : 0;
+   unsigned int ready = buf->subbufs_produced - buf->subbufs_consumed;
+   return (ready >= buf->chan->n_subbufs) ? 1 : 0;
 }
 
 /*
@@ -65,22 +55,13 @@ static inline int relay_buf_full(struct 
  */
 static int subbuf_start_default_callback (struct rchan_buf *buf,
 

relayfs as infrastructure, ltt, systemtap, diskstat

[bert hubert]

On Fri, Jul 22, 2005 at 01:01:32PM -0700, Paul Jackson wrote:
> Another vote in favor of relayfs here ...

At OLS the 'SystemTAP' idea was presented, which has been partially
implemented already, and it builds on relayfs as well. It dovetails nicely
with kprobes.

So it appears there is a sizeable amount of code which is building on
relayfs, iow, it is getting to be infrastructure.

I'm redoing diskstat to work with k/jprobes so it won't require a kernel
patch anymore, but it will still rely on relayfs.

So it would be tremendously helpful if relayfs would be part of the
mainline. I'll be banging out some HOWTO style documentation soonish.

Bert.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
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: kernel guide to space

[Jesper Juhl]

On 7/22/05, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 22, 2005 at 12:12:12PM -0500, Patrick Draper wrote:
> > Why isn't a code formatting program used? People could write the code
> > as they like to write it, then format it automatically in a standard
> > way before it gets put into the kernel.
> There is.
> scripts/Lindent
> 
> But sometimes it fails to do the job properly and some hand formatting
> is needed. Also much of the kernel is not new stuff but expanding or
> fixing old stuff.
> 
Ehh, that's exactely why I wrote "You can do some cleanup that way,
but not everything..."

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

Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)

[Matthew Helsley]

On Fri, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:


> actually, let me also say that CKRM is on a continuum that includes 
> current (global) /proc tuning for various subsystems, ulimits, and 
> at the other end, Xen/VMM's.  it's conceivable that CKRM could wind up
> being useful and fast enough to subsume the current global and per-proc
> tunables.  after all, there are MANY places where the kernel tries to 
> maintain some sort of context to allow it to tune/throttle/readahead
> based on some process-linked context.  "embracing and extending"
> those could make CKRM attractive to people outside the mainframe market.

Seems like an excellent suggestion to me! Yeah, it may be possible to
maintain the context the kernel keeps on a per-class basis instead of
globally or per-process. The real question is what constitutes a useful
"extension" :).

I was thinking that per-class nice values might be a good place to
start as well. One advantage of per-class as opposed to per-process nice
is the class is less transient than the process since its lifetime is
determined solely by the system administrator.

CKRM calls this kind of module a "resource controller". There's a small
HOWTO on writing resource controllers here:
http://ckrm.sourceforge.net/ckrm-controller-howto.txt
If anyone wants to investigate writing such a controller please feel
free to ask questions or send HOWTO feedback on the CKRM-Tech mailing
list at .

Thanks,
-Matt Helsley

-
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.13-rc3 dma_timer_expiry

[Sanjoy Mahajan]

>From my previous message on this subject:

> With 2.6.13-rc3 I now get these errors (2.6.11.4 was fine) on my TP
> 600X (Debian 'etch' system):
> 
> localhost kernel: hda: dma_timer_expiry: dma status == 0x21
> localhost kernel: hda: DMA timeout error

> localhost kernel: hda: dma timeout error: status=0x58 { DriveReady
> SeekComplete DataRequest }

I just narrowed the problem to an interaction with the tpctl tools.

If I turn off /etc/init.d/tpctl (turn its sysV symlinks into K* links),
I get no DMA errors.  I can then reproduce the errors by
   /etc/init.d/tpctl start
(which runs tpctl and loads the smapi and thinkpad modules), as long as
I am in runlevel 2 or higher.  If I'm in runlevel 1, I get no errors.

I'm using Debian's tpctl package (4.17-1).  With kernel 2.6.13-rc3, I'm
using the thinkpad modules from Debian's thinkpad-source (5.8-4)
package.  With 2.6.11.4 I use the 5.8-3 package for the source, but it's
almost the same as 5.8-4.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal
-
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: kernel optimization

[Adrian Bunk]

On Fri, Jul 22, 2005 at 12:52:22PM -0700, David Lang wrote:

> This is a airly frequent question
> 
> the short answer is 'don't try'
> 
> the longer answer is that all the additional optimization options that are 
> part of O3+ are considered individually and if they make sense for the 
> kernel they are explicitly enabled (in some cases the optimizations need 
> to be explicitly turned off for proper functionality of the kernel under 
> all versions of GCC)

As far as I can see, none of the additional optimizations with -O3 is 
enabled in the kernel.

> David Lang

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: kernel optimization

[Adrian Bunk]

On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:

> hello

Hi Chris,

> i would like to ask if it possible to change the optimization of the 
> kernel from -O2 to -O3 :D, how can i do that? if i change it to the top 
> level Makefile does it change to all the Makefiles?

search for the line with
  CFLAGS  += -O2
and change this to -O3.

This works for most Makefile's except for the one's that manually
set -Os.

> And let's say that i change it... does this generate any problems with 
> the space that the kernel will take? (the kernel will be much larger)

It's completely untested.
And since it's larger, it's also slower.

> Thanks
> Chris

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: slow tcp acks on loopback device

[David S. Miller]

From: Steve French <[EMAIL PROTECTED]>
Date: 22 Jul 2005 14:56:59 -0500

> Noticing that the loopback device (at least on RHEL4) has an unfortunate
> mtu size 16384 (which is about 50 bytes too small for SMB read
> responses), I did try increasing the MTU slightly.  Changing that to
> 18000 did avoid the fragmentation and the 40ms delay - but what puzzled
> me was why setting TCP_NODELAY after the socket was created did not
> eliminate the delay on the ack and if there is a way to avoid the huge
> tcp ack delay by either doing something else to force client acking
> immediately or to do something on the client side of the stack to get
> the server to send the whole 16K+ frame - it looks like the tcp windows
> is 32K if the value in the tcp acks in the network trace is to be
> trusted.

TCP_NODELAY does not control ACK generation, instead it modifies
the Nagle algorithm behavior when sending data packets.

Please take networking discussions to netdev@vger.kernel.org which
is where the networking developers are.
-
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: slow tcp acks on loopback device

[Steve French]

On Fri, 2005-07-22 at 14:56, Steve French wrote:
> I am seeing odd tcp characteristics on the loopback device.

Although probably not related ... I thought it worth mentioning that
ethereal claims bad tcp checksum on the 2nd of each pair of tcp response
frames (the smaller one) when run on the loopback device.   When the mtu
is increased, ethereal reports no tcp checksum error.

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

Re: [PATCH] Re: relayfs documentation sucks?

[Paul Jackson]

Another vote in favor of relayfs here ...

I am reminded by my good colleagues at SGI that relayfs is a key
to the Linux Trace Toolkit (LTT), which is in turn an important
technology for some product(s) on which SGI is working.

It is uses such as this which speak to the value of including
relayfs in the kernel.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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/

slow tcp acks on loopback device

[Steve French]

I am seeing odd tcp characteristics on the loopback device.

In analyzing cifs read performance to samba, I see a fairly consistent
pattern.

TCP frame containing SMBRead request (asking for size 16K)
1st 16K of SMB Read Response  (1 ms later or less) sent from samba
Samba's response is just over 16K (due to protocol header)
wait 40ms doing nothing AFAIK
tcp ack from client to server
TCP frame with last few bytes of the SMB ReadResponse
TCP frame containing next SMB Read Request (asking for size 16K) etc.

I added a setsockopt call to cifs's ipv4_connect to set TCP_NODELAY to 1
(done once just after the connect) which did not seem to help.

Noticing that the loopback device (at least on RHEL4) has an unfortunate
mtu size 16384 (which is about 50 bytes too small for SMB read
responses), I did try increasing the MTU slightly.  Changing that to
18000 did avoid the fragmentation and the 40ms delay - but what puzzled
me was why setting TCP_NODELAY after the socket was created did not
eliminate the delay on the ack and if there is a way to avoid the huge
tcp ack delay by either doing something else to force client acking
immediately or to do something on the client side of the stack to get
the server to send the whole 16K+ frame - it looks like the tcp windows
is 32K if the value in the tcp acks in the network trace is to be
trusted.

-
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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)

[Theodore Ts'o]

On Fri, Jul 22, 2005 at 07:34:38PM +0530, Milind Dumbare wrote:
> Hi,
> 
>   LinSysSoft Technologies  has taken up the challenge to incorporate
> Checkpoint and Block Level Incremental Backup (BLIB) support in the open
> source's Ext3 File System, which is very well known for its stability,
> to create a new file system called CheckFS. Block Level Incremental
> Backup enables truly efficient backup and restore mechanisms.
> Checkpoints provide administrators to create point-in-time copies of a
> live file system by keeping track of the data blocks modified in real
> time. 
> 
> For further information and a downloadable working prototype of this
> technology go to : http://checkfs.linsyssoft.com

This looks like very interesting technology, but out of curiosity, why
did you develop this as separate filesystem with a new filesystem
name, and doing a global search-and-replace of "ext3" with "checkfs"
in the source files, instead of simply just modifying ext3 and posting
diffs?  Especially since that the apparent intention is to keep ext3
compatibility using the same ext3 magic numbers, data formats, and
user-mode utilities.

I'll reserve the superblock fields and compatibility bitmap fields
used by your code in e2fsprogs to help avoid the possibility of other
folks working on ext3 extensions from colliding with the codepoints
which you "borrowed", but in the future, it would be good if people
contact me in advance so I ensure that there are no collisions with
other development groups.

What version of the source base did you originally fork checkfs from?
That way we can do a "s/checkfs/ext3/g" search and replace and then
generate some diffs to see what you changed, or alternatively, it
would be even better if you minimized differences between your version
and mainline and generated the diffs yourself.

Thanks, regards, 

- Ted

-
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.13-rc3-mm1 (ckrm)

[Paul Jackson]

Shailabh wrote:
> So if the current CPU controller 
>   implementation is considered too intrusive/unacceptable, it can be 
> reworked or (and we certainly hope not) even rejected in perpetuity. 

It is certainly reasonable that you would hope such.

But this hypothetical possibility concerns me a little.  Where would
that leave CKRM, if it was in the mainline kernel, but there was no CPU
controller in the mainline kernel?  Wouldn't that be a rather serious
problem for many users of CKRM if they wanted to work on mainline
kernels?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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: kernel optimization

[David Lang]

This is a airly frequent question

the short answer is 'don't try'

the longer answer is that all the additional optimization options that are 
part of O3+ are considered individually and if they make sense for the 
kernel they are explicitly enabled (in some cases the optimizations need 
to be explicitly turned off for proper functionality of the kernel under 
all versions of GCC)


David Lang

On Fri, 22 Jul 2005, christos gentsis wrote:


Date: Fri, 22 Jul 2005 19:55:48 +0100
From: christos gentsis <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: kernel optimization

hello

i would like to ask if it possible to change the optimization of the kernel 
from -O2 to -O3 :D, how can i do that? if i change it to the top level 
Makefile does it change to all the Makefiles?


And let's say that i change it... does this generate any problems with the 
space that the kernel will take? (the kernel will be much larger)


Thanks
Chris

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



--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Memory Management

[Márcio Oliveira]

Neil Horman wrote:


On Fri, Jul 22, 2005 at 11:32:52AM -0300, Márcio Oliveira wrote:
 


Neil Horman wrote:

   


On Thu, Jul 21, 2005 at 10:40:54AM -0300, Márcio Oliveira wrote:


 


http://people.redhat.com/nhorman/papers/rhel3_vm.pdf
I wrote this with norm awhile back.  It may help you out.
Regards
Neil


   

 


Neil,

Thanks.~10-12GB of total RAM (16GB) are

How can Proc virtual memory parameters like inactive_clean_percent, 
overcommit_memory, overcommit_ratio and page_cache help me to solve / 
reduce Out Of Memory conditions on servers with 16GB RAM and lots of GB 
swap?


 

   


I wouldn't touch memory overcommit if you are already seeing out of memory
issues.  If you are using lots of pagecache, I would suggest increasing
inactive_clean percent, reducing the pagecahce.max value, and modifying the
bdflush parameters in the above document such that bdflush runs sooner, 
more

often, and does more work per iteration.  This will help you move data in
pagecache back to disk more aggressively so that memory will be available 
for
other purposes, like heap allocations. Also if you're using a Red Hat 
kernel and
you have 16GB of ram in your system, you're a good candidate for the 
hugemem

kernel.  Rather than a straightforward out of memory condition, you may be
seeing a exhaustion of your kernels address space (check LowFree in
/proc/meminfo).  In this even the hugemem kernel will help you in that it
increases your Low Memory address space from 1GB to 4GB, preventing some 
OOM

conditions.




 

Kernel does not free cached memory (~10-12GB of total RAM - 16GB). Is 
there some way to force the kernel to free cached memory?


 

   

Cached memory is freed on demand.  Just because its listed under the 
cached line
below doesn't mean it can't be freed and used for another purpose.  
Implement

the tunings above, and your situation should improve.

Regards
Neil



 


/proc/meminfo:

  total:used:free:  shared: buffers:  cached:
Mem:16603488256 1652632 801546240 70651904 13194563584
Swap:   17174257664 11771904 17162485760
MemTotal: 16214344 kB
MemFree: 78276 kB
Buffers: 68996 kB
Cached:   12874808 kB

Thanks to all.

Marcio.
 

   


Neil,

 Thanks for the answers!

The following lines are the Out Of Memory log:

Jul 20 13:45:44 server kernel: Out of Memory: Killed process 23716 (oracle).
Jul 20 13:45:44 server kernel: Fixed up OOM kill of mm-less task
Jul 20 13:45:45 server su(pam_unix)[3848]: session closed for user root
Jul 20 13:45:48 server kernel: Mem-info:
Jul 20 13:45:48 server kernel: Zone:DMA freepages:  1884 min: 0 
low: 0 high: 0
Jul 20 13:45:48 server kernel: Zone:Normal freepages:  1084 min:  1279 
low:  4544 high:  6304
Jul 20 13:45:48 server kernel: Zone:HighMem freepages:386679 min:   255 
low: 61952 high: 92928

Jul 20 13:45:48 server kernel: Free pages:  389647 (386679 HighMem)
Jul 20 13:45:48 server kernel: ( Active: 2259787/488777, 
inactive_laundry: 244282, inactive_clean: 244366, free: 389647 )

Jul 20 13:45:48 server kernel:   aa:0 ac:0 id:0 il:0 ic:0 fr:1884
Jul 20 13:45:48 server kernel:   aa:1620 ac:1801 id:231 il:15 ic:0 fr:1085
Jul 20 13:45:48 server kernel:   aa:1099230 ac:1157136 id:488536 
il:244277 ic:244366 fr:386679
Jul 20 13:45:48 server kernel: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 
1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 7536kB)Jul 20 13:45:48 
server kernel: 55*4kB 9*8kB 19*16kB 9*32kB 0*64kB 1*128kB 1*256kB 
0*512kB 1*1024kB 1*2048kB 0*4096kB = 4340kB)
Jul 20 13:45:48 server kernel: 291229*4kB 46179*8kB 711*16kB 1*32kB 
1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1546716kB)
Jul 20 13:45:48 server kernel: Swap cache: add 192990, delete 189665, 
find 21145/90719, race 0+0

Jul 20 13:45:48 server kernel: 139345 pages of slabcache
Jul 20 13:45:48 server kernel: 1890 pages of kernel stacks
Jul 20 13:45:48 server kernel: 0 lowmem pagetables, 274854 highmem 
pagetables

Jul 20 13:45:48 server kernel: Free swap:   16749720kB
Jul 20 13:45:49 server kernel: 4194304 pages of RAM
Jul 20 13:45:49 server kernel: 3899360 pages of HIGHMEM
Jul 20 13:45:49 server kernel: 140718 reserved pages
Jul 20 13:45:49 server kernel: 35350398 pages shared
Jul 20 13:45:49 server kernel: 3325 pages swap cached

/proc/meminfo LowFree info:
LowFree: 17068 kB--> Do you think this value is too low?

   


No that should be plenty of lowFree, but that number can change quickly
depending on workload.

 

Zone:Normal freepages:  1084 min:  1279 low:  4544 high:  6304   >  
(freepages < min) It's normal?
Zone:HighMem freepages:386679 min:   255 low: 61952 high: 92928  > 
(freepages < min) It's normal?


   


You're beneath your low water mark in the normal (lowmem) zone for free pages,
so your kernel is likely trying to get lots of data moved to disk.  Although
given that you're largest buddy list has a 2048K chunk free, I'm hard pressed to

Re: NAPI (aka RX Polling) for natsemi?

[Patrick McHardy]

Francois Romieu wrote:

Daniel Higgins <[EMAIL PROTECTED]> :
[napi for natsemi]

Can you please fill a bugzilla entry for it at bugzilla.kernel.org ?


It is bugzilla, not featurewishzilla. If some external patches
cause problem I suggest to contact their authors.
-
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: Supermount

[Lasse Kärkkäinen / Tronic]

> Supermount is obsolete there are other tools in userspace that do the
> job perfectly.
> e.g ivman which uses hal and dbus.

They cannot mount on demand, thus cannot do the same job. The boot
partition, for example, is something that should only be mounted when
required. The same obviously also goes for network filesystems in many
cases (i.e. avoid having zillion idling connections to the server).

> Also there are other fs like supermount e.g submount etc...

I woudldn't care about the implementation (original supermount,
supermountng, submount or something else). Getting the job done is what
counts.

- Tronic -


signature.asc
Description: OpenPGP digital signature

Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?

[linux-os \(Dick Johnson\)]

On Fri, 22 Jul 2005, vamsi krishna wrote:

> Hi,
>
>> It doesn't. The 32-bit machines never show 64 bit words in
>> /proc/NN/maps. They don't "know" how.
>>
>> b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0
>> b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0
>> bffe1000-bfff6000 rw-p bffe1000 00:00 0  [stack]
>> e000-f000 ---p  00:00 0  [vdso]
>>  32 bits
>
> hello john can you tell me what is [vdso], does it have any content
> related file descriptor table it seems that the if I dont save this
> segment during checkpointing,  the file open descriptors (i.e FILE *)
> seems to have null after restoration.
>
> Sincerely appreciate your inputs.
>
> Cheers!
> Vamsi
>

#include 

int main()
{
 long *foo = (long *)0xe000;
 printf("%08x\n", foo[0]);
 printf("%08x\n", foo[1]);
 printf("%08x\n", foo[2]);
 printf("%08x\n", foo[3]);
 printf("%08x\n", foo[4]);
 printf("%s\n", (char *)foo);

}

Seems to be readable and starts with 'ELF'. It's something
the the 'C' runtime may library use to make syscalls to the
kernel. Older libraries used interrupt 0x80, newer ones
may use this. Roland McGrath has made patches to this
segment so maybe he knows.



Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

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

Re: NAPI (aka RX Polling) for natsemi?

[Francois Romieu]

Daniel Higgins <[EMAIL PROTECTED]> :
[napi for natsemi]

Can you please fill a bugzilla entry for it at bugzilla.kernel.org ?

--
Ueimor
-
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: itimer oddness in 2.6.12

[Paulo Marques]

Tom Marshall wrote:

The patch to fix "setitimer timer expires too early" is causing issues for
the Helix server.  We have a timer processs that updates the server's
timestamp on an itimer and it expects the signal to be delivered at roughly
the interval retrieved from getitimer.  This is very consistent on every
platform, including Linux up to 2.6.11, but breaks on 2.6.12.  On 2.6.12,
setting the itimer to 10ms and retrieving the actual interval from getitimer
reports 10.998ms, but the timer interrupts are consistently delivered at
roughly 11.998ms.  


Unfortunately, this is not so clear cut as it seems :(

I tested this on my system again, and if I set the timer to 9900us and 
put the system to some load I get intervals as low as 10022us with a 
vanilla 2.6.12.2 kernel. Removing this patch would cause the system to 
give me 9022us intervals which is just unnacceptable.


The reason this misbehaves in your case is that 10ms is converted into 
11 jiffies. I'm not really an expert in the time subsystem, but I guess 
this happens because 1000HZ aren't _exactly_ 1000HZ, they're probably a 
little more, so to guarantee 10 ms, we need 11 jiffies (or there is a 
bug in the timeval->jiffies conversions).


If HZ is slightly greater than 1000, this means that each tick will come 
in slightly less than 1 ms. Lets assume we want 2 ms intervals:



---|||||--
^  ^  ^^
0  1  23

If you place your request at instant "1" and the time between ticks is 
slightly less than 1 ms, at instant "2" there is no guarantee that the 
time has ellapsed, only at instant "3" that is 4 ticks away. If you 
place that request at instant "0", you'll get almost 4ms.


So, the fact that 10 ms are converted to 11 jiffies explains why 
getitimer returns 10.998ms.


The fact that you are getting consistently 11.998ms just means that 
either your system is pretty idle, or the process that is requesting 
this timer has a very high priority so that it is able to request the 
timer again right after the timer tick (like in instant "0").


If this process is delayed for some reason and just requests the timer 
in the middle of the tick you would start seing values like 11.5ms.


If 10ms in jiffies would be just 10, then you would see 11ms between 
alarms, and getitimer would report 10ms.


The only way this could be better was if we knew "where" inside the tick 
we were when we set the timer (as discussed in the thread you 
mentioned), but in your case, even this wouldn't help because you're 
requesting a 10ms timer and to absolutely conform to the setitimer 
specification we can't just give you a 9.9ms interval.


Anyway, making the software depend on the time a timer takes to expire 
when the man page states "Timers will never expire before the requested 
time, ... the delivery will be offset by a small time dependent on the 
system loading" doesn't seem like a very robust software design to me...


--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

It is a mistake to think you can solve any major problems
just with potatoes.
Douglas Adams
-
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: Memory Management

[Neil Horman]

On Fri, Jul 22, 2005 at 11:32:52AM -0300, Márcio Oliveira wrote:
> Neil Horman wrote:
> 
> >On Thu, Jul 21, 2005 at 10:40:54AM -0300, Márcio Oliveira wrote:
> > 
> >
> >>>http://people.redhat.com/nhorman/papers/rhel3_vm.pdf
> >>>I wrote this with norm awhile back.  It may help you out.
> >>>Regards
> >>>Neil
> >>>
> >>>
> >>> 
> >>>
> >>Neil,
> >>
> >> Thanks.~10-12GB of total RAM (16GB) are
> >>
> >> How can Proc virtual memory parameters like inactive_clean_percent, 
> >>overcommit_memory, overcommit_ratio and page_cache help me to solve / 
> >>reduce Out Of Memory conditions on servers with 16GB RAM and lots of GB 
> >>swap?
> >>
> >>   
> >>
> >I wouldn't touch memory overcommit if you are already seeing out of memory
> >issues.  If you are using lots of pagecache, I would suggest increasing
> >inactive_clean percent, reducing the pagecahce.max value, and modifying the
> >bdflush parameters in the above document such that bdflush runs sooner, 
> >more
> >often, and does more work per iteration.  This will help you move data in
> >pagecache back to disk more aggressively so that memory will be available 
> >for
> >other purposes, like heap allocations. Also if you're using a Red Hat 
> >kernel and
> >you have 16GB of ram in your system, you're a good candidate for the 
> >hugemem
> >kernel.  Rather than a straightforward out of memory condition, you may be
> >seeing a exhaustion of your kernels address space (check LowFree in
> >/proc/meminfo).  In this even the hugemem kernel will help you in that it
> >increases your Low Memory address space from 1GB to 4GB, preventing some 
> >OOM
> >conditions.
> >
> >
> > 
> >
> >> Kernel does not free cached memory (~10-12GB of total RAM - 16GB). Is 
> >>there some way to force the kernel to free cached memory?
> >>
> >>   
> >>
> >Cached memory is freed on demand.  Just because its listed under the 
> >cached line
> >below doesn't mean it can't be freed and used for another purpose.  
> >Implement
> >the tunings above, and your situation should improve.
> >
> >Regards
> >Neil
> >
> > 
> >
> >>/proc/meminfo:
> >>
> >>total:used:free:  shared: buffers:  cached:
> >>Mem:16603488256 1652632 801546240 70651904 13194563584
> >>Swap:   17174257664 11771904 17162485760
> >>MemTotal: 16214344 kB
> >>MemFree: 78276 kB
> >>Buffers: 68996 kB
> >>Cached:   12874808 kB
> >>
> >>Thanks to all.
> >>
> >>Marcio.
> >>   
> >>
> 
> Neil,
> 
>   Thanks for the answers!
> 
> The following lines are the Out Of Memory log:
> 
> Jul 20 13:45:44 server kernel: Out of Memory: Killed process 23716 (oracle).
> Jul 20 13:45:44 server kernel: Fixed up OOM kill of mm-less task
> Jul 20 13:45:45 server su(pam_unix)[3848]: session closed for user root
> Jul 20 13:45:48 server kernel: Mem-info:
> Jul 20 13:45:48 server kernel: Zone:DMA freepages:  1884 min: 0 
> low: 0 high: 0
> Jul 20 13:45:48 server kernel: Zone:Normal freepages:  1084 min:  1279 
> low:  4544 high:  6304
> Jul 20 13:45:48 server kernel: Zone:HighMem freepages:386679 min:   255 
> low: 61952 high: 92928
> Jul 20 13:45:48 server kernel: Free pages:  389647 (386679 HighMem)
> Jul 20 13:45:48 server kernel: ( Active: 2259787/488777, 
> inactive_laundry: 244282, inactive_clean: 244366, free: 389647 )
> Jul 20 13:45:48 server kernel:   aa:0 ac:0 id:0 il:0 ic:0 fr:1884
> Jul 20 13:45:48 server kernel:   aa:1620 ac:1801 id:231 il:15 ic:0 fr:1085
> Jul 20 13:45:48 server kernel:   aa:1099230 ac:1157136 id:488536 
> il:244277 ic:244366 fr:386679
> Jul 20 13:45:48 server kernel: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 
> 1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 7536kB)Jul 20 13:45:48 
> server kernel: 55*4kB 9*8kB 19*16kB 9*32kB 0*64kB 1*128kB 1*256kB 
> 0*512kB 1*1024kB 1*2048kB 0*4096kB = 4340kB)
> Jul 20 13:45:48 server kernel: 291229*4kB 46179*8kB 711*16kB 1*32kB 
> 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1546716kB)
> Jul 20 13:45:48 server kernel: Swap cache: add 192990, delete 189665, 
> find 21145/90719, race 0+0
> Jul 20 13:45:48 server kernel: 139345 pages of slabcache
> Jul 20 13:45:48 server kernel: 1890 pages of kernel stacks
> Jul 20 13:45:48 server kernel: 0 lowmem pagetables, 274854 highmem 
> pagetables
> Jul 20 13:45:48 server kernel: Free swap:   16749720kB
> Jul 20 13:45:49 server kernel: 4194304 pages of RAM
> Jul 20 13:45:49 server kernel: 3899360 pages of HIGHMEM
> Jul 20 13:45:49 server kernel: 140718 reserved pages
> Jul 20 13:45:49 server kernel: 35350398 pages shared
> Jul 20 13:45:49 server kernel: 3325 pages swap cached
> 
> /proc/meminfo LowFree info:
> LowFree: 17068 kB--> Do you think this value is too low?
> 
No that should be plenty of lowFree, but that number can change quickly
depending on workload.

> Zone:Normal freepages:  1084 min:  1279 low:  4544 high:  6304   >  
> (freepages < min) It's normal?
> Zone:HighMem freepages:386679 min:   255 low: 61952 high: 92928  > 

Re: 2.6.13-rc3-mm1 (ckrm)

[Alan Cox]

On Gwe, 2005-07-22 at 12:35 -0400, Mark Hahn wrote:
> I imagine you, like me, are currently sitting in the Xen talk,

Out by a few thousand miles ;)

> and I don't believe they are or will do anything so dumb as to throw away
> or lose information.  yes, in principle, the logic will need to be 

They don't have it in the first place. 

> somewhere, and I'm suggesting that the virtualization logic should
> be in VMM-only code so it has literally zero effect on host-native 
> processes.  *or* the host-native fast-path.

I don't see why you are concerned. If the CKRM=n path is zero impact
then its irrelevant to you. Its more expensive to do a lot of resource
management at the VMM level because the virtualisation engine doesn't
know anything but its getting indications someone wants to be
bigger/smaller.


> but to really do CKRM, you are going to want quite extensive interaction with
> the scheduler, VM page replacement policies, etc.  all incredibly
> performance-sensitive areas.

Bingo - and areas the virtualiser can't see into, at least not unless it
uses the same hooks CKRM uses

Alan

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