SKGE surely isn't a meta driver. Not that this is relevant at all...
Signed-off-by: Tim Schmielau <[EMAIL PROTECTED]>
--- linux-2.6.13/drivers/net/Kconfig2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13-skge/drivers/net/Kconfig 2005-09-08 10:57:38.0
+0200
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Well your patch certainly cleans things up in there and would be a good
> thing to have as long as we can be sure that it doesn't break the
> accounting in some subtle way.
I think it also fits well with the other accounting data which is only
statistic
> Hi Vise People,
>
>
> ASUS P2B-DS board seems NOT work very well with default kernel in FED
> Core 3. smp-kernel hangs booting at various stages. I am goig to try
> 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to
> test with smp-kernels so I don't know what I could try.
The ppid of a process is not really helpful if I want to reconstruct the
real history of processes on a machine, since it may become 1 when the
parent dies and the process is reparented to init.
I am not aware of concepts in Linux or other unices that apply to this
case. So I made up the "biologi
On Mon, 31 Jan 2005, Michael Buesch wrote:
> Quoting Tim Schmielau <[EMAIL PROTECTED]>:
> > The ppid of a process is not really helpful if I want to reconstruct the
> > real history of processes on a machine, since it may become 1 when the
> > parent dies and the pr
On Tue, 1 Feb 2005, Helge Hafting wrote:
> Tim Schmielau wrote:
>
> >
> >I'm trying to reconstruct the complete history of processes from the
> >BSD accounting records. However, this is not very useful if a large
> >fraction of the processes look as if th
On Tue, 1 Feb 2005, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I am not aware of concepts in Linux or other unices that apply to this
> > case.
>
> Normal process accounting.
Sure. That's what the patch was made for. Or do you have anything else
in mind than BSD accou
On Tue, 1 Feb 2005, Bill Davidsen wrote:
> Tim Schmielau wrote:
> > The ppid of a process is not really helpful if I want to reconstruct the
> > real history of processes on a machine, since it may become 1 when the
> > parent dies and the process is reparented to init.
&g
On Thu, 3 Feb 2005, Pankaj Agarwal wrote:
> In my system there's a strange behaviour its not allowing me to create
> any file in /usr/bin even as root. Its chmod is set to 755. Its even not
> allowing me to change the chmod value of /usr/bin. The strangest part which
> i felt is ...its show
On Tue, 22 Feb 2005, Andrew Morton wrote:
> We really want to avoid doing such stuff in-kernel if at all possible, of
> course.
>
> Is it not possible to implement the fork/exec/exit notifications to
> userspace so that a daemon can track the process relationships and perform
> aggregation based
On Fri, 25 Feb 2005, Mark Fortescue wrote:
> The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be
> correct. I had some errors during patching so I generated a diff against a
> freshly downloaded linux-2.6.10 kernel. See the steps below:
>
> 1) bzcat linux-2.6.8.1.tar.bz2 | tar
> > +#ifdef CONFIG_FORK_CONNECTOR
[...]
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
[...]
> > +}
> > +#else
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
> > + return;
> > +}
> > +#endif
[...]
> > @@ -1238,6 +1281,8 @@ long do_fork(unsig
On Wed, 2 Mar 2005, Guillaume Thouvenin wrote:
> Is it possible to merge BSD and CSA? I mean with CSA, there is a part
> that does per-process accounting. For exemple in the
> linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and
> csa_update_integrals() update fields in the current
> Monotonic clocks could be calculated
>
> monotime = ns_at_last_tick + (time_source_cycles_since_tick *
> current_scaling_factor) >> shift_factor.
>
> This would also be easy to implement in asm if necessary.
>
> tick processing could then increment or decrement the current scaling
> factor to
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
> Centralize the attribute macro definition of "__packed" so no
> subsystem has to do that explicitly.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> compile tested to make sure the HFS subsystem still builds. now
> there's
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
> actually, it *appears* that the standard works this way. the macro
> "__deprecated" is defined in compiler-gcc.h with:
>
> #define __deprecated __attribute__((deprecated))
>
> while the more generic compiler.h handles whether or not it was
> de
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads: 74 MB in 3.01 seconds
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. Fo
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> Anyway, in your situation with a very small buffer, this should not
> change by more than half a second or so.
Well, his buffer is not small. He has half a GB of RAM, so when
writing 1 GB the buffer would roughly double the dd speed, exactly as he
ha
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlighteni
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> > On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > > also explains why yo
On Sun, 21 Jan 2007, Sunil Naidu wrote:
> On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
&g
).
Signed-off-by: Tim Schmielau <[EMAIL PROTECTED]>
Patch attached as .bz2 due to it's size (160k uncompressed).
remove-556-unneeded-includes-of-schedh.patch.bz2
Description: BZip2 compressed data
After fiddling with this patch for so long, I forgot to mention an
important thing:
This time the patch only includes things that need no fixups at all (most
of these already went in last time).
So all hunks are independent, and you can just drop anything that does not
apply or causes any other
On Thu, 28 Dec 2006, Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[EMAIL PROTECTED]> wrote:
>
> > After Al Viro (finally) succeeded in removing the sched.h #include in
> > module.h recently, it makes sense again to remove oth
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> I'm half done with a patch to remove includes of smp_lock.h.
> For the files that I have patched, I checked each source file
> for all interfaces in smp_lock.h to verify that none of them
> are used, so the #include is just waste.
Yes, that's what I also
On Thu, 28 Dec 2006, Al Viro wrote:
> Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and
allyesconfig as well as a few randconfigs on x86_64
On Thu, 28 Dec 2006, Russell King wrote:
> To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?
> The whole "all*config" ide
On Thu, 28 Dec 2006, Russell King wrote:
> Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing something wrong or are
you talking about native builds?
Tim
-
To u
On Thu, 28 Dec 2006, Russell King wrote:
> I'm talking about cross-builds... I don't know the spec of the machine,
> only that it's x86 based (I don't run it.)
>
> The last report at the beginning of this month said: 11 1/2 hours per
> git snapshot, which is apparantly for building a total of ab
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > > The whole "all*config" idea on ARM is utterly useless - you can _n
On Thu, 28 Dec 2006, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
>
> > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
>
> OK, I'll try to do that.
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> Yep, right, if I already had all of that cross-build stuff setup,
> it wouldn't be a big deal. But getting it all setup is a big deal
> (to me).
Well, I didn't want to say that you specifically should do that. ;-)
OTOH, if you are interested, setting i
On Fri, 29 Dec 2006, Tim Schmielau wrote:
> Andrew, please use the attached patch instead of the previous one, it also
> has a slightly better patch description.
This time I actually attached something. Sorry.
(In case anybody wonders: yes, I did get some sleep while the builds were
r
Well, on a P4 (which is supposed to be soo bad) I get:
> gcc -O2 t.c -o t
> foreach x ( 1 2 3 4 5 )
>> time ./t > /dev/null
>> end
0.196u 0.004s 0:00.19 100.0%0+0k 0+0io 0pf+0w
0.168u 0.004s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.168u 0.000s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.160u 0.000s 0:0
On Tue, 27 Feb 2007, Andrew Morton wrote:
> > On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger <[EMAIL PROTECTED]>
> > wrote:
> > The kernel already has several implmentations and usages of 64 by 64
> > bit divide.
> >
> > Although it is significantly slower, there are places that need it so
On Sun, 4 Feb 2007, Mathieu Desnoyers wrote:
> kernel/time/clocksource.c needs struct task_struct on m68k.
>
> Because it uses spin_unlock_irq(), which, on m68k, uses hardirq_count(), which
> uses preempt_count(), which needs to dereference struct task_struct, we
> have to include sched.h. Becaus
On Wed, 14 Feb 2007, Johann Schuster wrote:
> currently i'm trying to measure the cpu times for
> numerical algorithms written in C using two calls of
> getrusage() and then calculating the time difference.
>
> According to the man page of getrusage i looked at the
> user time of my process. Surp
On Fri, 16 Feb 2007, Andrew Morton wrote:
> No, that's still crufty. There's no reason why marker.h needs special
> treatment whereas, say, jiffies.h does not (is there?)
Unforunately, even jiffies.h gets special treatment. sched.h still
includes jiffies.h, as this is where it was originally de
On Fri, 26 Jan 2007, Oleg Verych wrote:
> In Debian's version it has no `bc', while native `bc' is producing
> crap like that:
> ,-*- bash -*-
> |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> |18446744073709551615
> |[EMAIL PROTECTED]:~$ echo -1 | bc
> |-1
> |[EMAIL PROTECTED]:~$ printf "%u"
On Tue, 30 Jan 2007, Tom Burns wrote:
> The bug described back in 2004 in the following message still seems to exist:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
>
> Essentially, it appears that if a process sleeps before it uses up a
> complete jiffy then no charge is
On Tue, 30 Jan 2007, Tom Burns wrote:
> That would be great if you could find that patch - I can worry about
> porting it to the current kernel. We're having an issue where our
> device, while routing large amounts of network traffic, reports 0% CPU
> utilisation when it cannot be the case, and I
On Thu, 1 Feb 2007, David Howells wrote:
> Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> > +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1))
>
> If this is such a commonly implemented op, it should probably be implemented
> globally too.
>
> I also wonder if there's some better way
On Thu, 1 Feb 2007, [EMAIL PROTECTED] wrote:
> On Thu, 01 Feb 2007 13:39:15 +0100, Tim Schmielau said:
> > #define is_power_of_4(x) (is_power_of_2_or_zero(x) \
> > && (x & ((typeof(x))0x)))
>
> Those 5's are going to n
On Sun, 4 Feb 2007, Ahmed S. Darwish wrote:
> On Sat, Feb 03, 2007 at 11:56:16PM +0100, Richard Knutsson wrote:
> > So:
> >
> > if (is_true()) {
> > /* do something */
> > }
> >
> > is alright then? If so, I agree, but please make it real clear in the
> > document ;)
>
> Good catch :). A sm
On Sun, 3 Dec 2006, Aucoin wrote:
> during tar extraction ... inactive pages reaches levels as high as ~375000
So why do you want the system to swap _less_? You need to find some free
memory for the additional processes to run in, and you have lots of
inactive pages, so I think you want to swap
On Mon, 4 Dec 2006, Aucoin wrote:
> > From: Horst H. von Brand [mailto:[EMAIL PROTECTED]
> > That means that there isn't a need for that memory at all (and so they
>
> In the current isolated non-production, not actually bearing a load test
> case yes. But if I can't get it to not swap on an idle
> but it still leaves an open issue -- once one submits a patch, is there
> *any* official feedback that one can look for to see if it's been
> accepted/rejected/dropped on the floor/whatever?
You can regularely pull Linus' tree (or the tree of the maintainer you
sent your patch) and see whethe
On Fri, 15 Dec 2006, Robert P. J. Day wrote:
> On Fri, 15 Dec 2006, Jan Engelhardt wrote:
> > Even sizeof a / sizeof *a
> >
> > may happen.
>
> yes, sadly, there are a number of those as well. back to the drawing
> board.
It might be interesting to grep for anything that divides two sizeofs and
On Sat, 16 Dec 2006, Robert P. J. Day wrote:
> On Fri, 15 Dec 2006, Tim Schmielau wrote:
> >
> > It might be interesting to grep for anything that divides two
> > sizeofs and eyeball the result for possible mistakes. This would
> > provide some real benefit beyond the
On Sat, 16 Dec 2006, J.H. wrote:
> - Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line "unsubscribe linu
On Fri, 5 Jan 2007, Mariusz Kozlowski wrote:
> Doesn't build on my iMac G3 based garage jukebox ;-)
>
> arch/powerpc/kernel/of_platform.c:479: error: unknown field
> 'multithread_probe' specified in initializer
> arch/powerpc/kernel/of_platform.c:479: warning: initialization makes pointer
On Sat, 6 Jan 2007, Stefan Richter wrote:
> Did anybody else notice this? The result of "hdparm -t" under 2.6.20-rc
> seems to be less than half of what you get on 2.6.19. However, disk I/O
> did *not* get slower according to bonnie++.
yes. See
http://lkml.org/lkml/2007/1/2/75
for the solutio
On Wed, 10 Jan 2007, Geert Uytterhoeven wrote:
> which needs the definition of struct task_struct.
>
> The patch below fixes it by including in
> kernel/time/clocksource.c. But perhaps this is the right time to move
> struct task_struct to its own include instead?
I used to post such a patch on
> Chase Venters (1):
> Fix jiffies.h comment
This one actually obscures the comment rather than fixing it.
>From jiffies.h:
> 76 /*
> 77 * The 64-bit value is not volatile - you MUST NOT read it
> 78 * without sampling the sequence number in xtime_lock.
> 79 * get_jiffies_64() will do th
On Fri, 1 Dec 2006, Adrian Bunk wrote:
> On Fri, Dec 01, 2006 at 01:41:18PM +0100, Tim Schmielau wrote:
[...]
> > would leave a comment that is correct, but less useful (I'd expect any
> > kernel hacker to know that u64 is non-atomic on many platforms).
>
>
> If k
56 matches
Mail list logo
