et *sock);
+void Send408(struct socket *sock);
void Send304(struct socket *sock);
void Send50x(struct socket *sock);
diff -urN linux-orig/net/khttpd/rfc.c linux/net/khttpd/rfc.c
--- linux-orig/net/khttpd/rfc.c Mon Aug 23 10:41:25 1999
+++ linux/net/khttpd/rfc.c Fri Jan 12 21:23:26 2001
@
On Fri, 12 Jan 2001, dean gaudet wrote:
> anyhow a real network benchmark might show that kHTTPd latency is actually
> not as broken as this one indicates. i'd however really hesitate to call
> this a win.
Well as Arjan says: khttpd starves userspace and that might cause the
latency. I dont hav
truct http_request *request);
int SendBuffer(struct socket *sock, const char *Buffer,const size_t Length);
int SendBuffer_async(struct socket *sock, const char *Buffer,const size_t Length);
void Send403(struct socket *sock);
+void Send408(struct socket *sock);
void Send304(struct socket *so
With both version I get the "booting linux" message and then the first
line of the kernel messages. Then its dead. Have tried to change the kernel
configuration but to no avail.
2.4.0test2 works fine.
How can I figure out what is wrong?
-
To unsubscribe from this list: send the line "unsubsc
On 18 Sep 2000, Juan J. Quintela wrote:
> >>>>> "christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes:
>
> christoph> With both version I get the "booting linux" message and then the first
> christoph> line of the kernel
On Sun, Sep 17, 2000 at 06:14:11PM -0700, Christoph Lameter wrote:
> With both version I get the "booting linux" message and then the first
> line of the kernel messages. Then its dead. Have tried to change the kernel
> configuration but to no avail.
The problem was that
Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
is empty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 19 Sep 2000, Marko Kreen wrote:
> On Tue, Sep 19, 2000 at 09:32:09AM -0700, Christoph Lameter wrote:
> > Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
> > is empty.
> It 'moved'. Do a 'cd /dev/scsi; ln ../host0' for tem
I frequently experience lockups since test9-pre7. It usually happens when
leaving pine. Pine asks if the deleted messages should be purged. Say yes
and everything freezes up.
Kernel configuration (Debian woody + pine 4.21)
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG
Is there something wrong with the tcp stack?
bash-2.04$ ping linuxtoday.com
PING linuxtoday.com (63.236.72.248) from 216.59.82.89 : 56 data bytes
64 bytes from 63.236.72.248: icmp_seq=0 ttl=244 time=103.7 ms
64 bytes from 63.236.72.248: icmp_seq=1 ttl=244 time=104.3 ms
--- linuxtoday.com ping
On Wed, 4 Oct 2000, Andi Kleen wrote:
> On Wed, Oct 04, 2000 at 09:34:18AM -0700, Christoph Lameter wrote:
> > Is there something wrong with the tcp stack?
>
> More with their firewall. But try
>
> echo 0 > /proc/sys/net/ipv4/tcp_ecn
Wow. I suddenly can access lots
On Tue, 3 Oct 2000, Rik van Riel wrote:
> On Tue, 3 Oct 2000, Christoph Lameter wrote:
>
> > I frequently experience lockups since test9-pre7. It usually
> > happens when leaving pine. Pine asks if the deleted messages
> > should be purged. Say yes a
Comparing CD contents with the original after burning showed mismatches 4
times in a row. Booted into linux 2.2.18 and everything is fine.
Together with the events of freezing in pine I would suggest that there is
something in the kernel scribbling memory.
I am back to 2.2 for good for now.
-
I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
rm hangs...
ls gives the following output:
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb:
On Mon, 26 Mar 2001, Chris Mason wrote:
> On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
>
> > I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
> >
> > rm hangs...
> >
> > ls g
On Mon, 26 Mar 2001, Chris Mason wrote:
> On Monday, March 26, 2001 03:21:29 PM -0800 Christoph Lameter
> > On Mon, 26 Mar 2001, Chris Mason wrote:
> >> On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
> >> <[EMAIL PROTECTED]> wrote:
> >>
On Tue, 27 Mar 2001, Chris Mason wrote:
> On Monday, March 26, 2001 06:57:37 PM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 26 Mar 2001, Chris Mason wrote:
> >> On Monday, March 26, 2001 03:21:29 PM -0800 Christoph Lameter
> >> >
On Tue, 27 Mar 2001, Chris Mason wrote:
> On Tuesday, March 27, 2001 08:21:07 AM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
>
> >
> > <-debugreiserfs, 2000->
> > reiserfsprogs
On Tue, 27 Mar 2001, Chris Mason wrote:
> Just to make sure I understand, you had the exact same errors before
> running fsck? Same files could not be deleted?
Correct.
> > I think this is a problem with the reiserfs code in the kernel. I never
> > ran reiserfsck before this problem surfaced. T
On Tue, 27 Mar 2001, Chris Mason wrote:
> On Tuesday, March 27, 2001 11:14:57 AM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
> I should have been more clear. Everyt ime you mount the filesystem, a it
> prints the hash used. This is probably recorded in your log file
t *sock, const char *Buffer,const size_t Length);
int SendBuffer_async(struct socket *sock, const char *Buffer,const size_t Length);
void Send403(struct socket *sock);
+void Send408(struct socket *sock);
void Send304(struct socket *sock);
void Send50x(struct socket *sock);
diff -urN linux/ne
These tests were done with 2 Celeron-433 processors across a 100 mbit
link.
The server was running 2.4.1-pre8 + my patches and boa / apache / khttpd.
The server was running other services while doing the test.
The client was running 2.2.17.
Boa is still very close to khttpd. Apache falls way be
On Thu, 24 Mar 2005, David Mosberger wrote:
> That's definitely the case. See my earlier post on this topic:
>
> http://www.gelato.unsw.edu.au/linux-ia64/0409/11012.html
>
> Unfortunately, nobody reported any results for larger machines and/or
> more interesting workloads, so the patch is in li
On Tue, 5 Apr 2005, David Mosberger wrote:
> What LMbench test other than fork/exec would you have expected to be
> affected by this? LMbench is not a good benchmark for this (remember:
> it's a _micro_ benchmark).
LMbench does a variety of things and I expected to see at least
something on the
On Thu, 7 Apr 2005, Nick Piggin wrote:
> Kumar Gala wrote:
> > ptep_get_and_clear has a signature that looks something like:
> >
> > static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned
> > long addr,
> >pte_t *ptep)
> >
> > It appears that
On Wed, 6 Apr 2005, Jon Smirl wrote:
> There is a large difference in the behavior of corporations with huge
> source bases and college students with no money. The corporations will
> pay to have someone responsible for ensuring that the product works.
Or they will merge with some other entity on
. Forbes <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.11/drivers/block/as-iosched.c
===
--- linux-2.6.11.orig/drivers/
an array of cpumasks anymore. Instead an
array of nodes is build which can be used to generate the cpumask via
node_to_cpumask.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.11/arch/x86_64/kern
Following is a series of oopses that kept my server not responding for a
while this morning. Running lots of services amoung them a hub for the
openproject IRC network:
May 30 07:58:01 melchi kernel: invalid operand:
May 30 07:58:01 melchi kernel: CPU:0
May 30 07:58:01 melchi kernel: EIP
On Thu, 14 Jul 2005, Lee Revell wrote:
> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> > - there are real-time applications (robotic environments: fast rotating
> >tools, media and mobile/phone applications, etc.) that want 10
> >usecs precision. If such users increased HZ to 10
On Thu, 7 Jul 2005, David Gibson wrote:
> Now that the hugepage code has been consolidated across the
> architectures, it becomes much easier to implement copy-on-write.
> Hugepage COW is of limited utility of itself, however, it is
> essentially a prerequisite for any of a number of methods of al
On Thu, 14 Jul 2005, Linus Torvalds wrote:
> So the _sane_ way to do timeouts is to define an _arbitrary_ clock that is
> just an integer counter. None of this "nanoseconds + full seconds" crap.
> None of this stupid confusion with "real time". You select something that
> is conceptually _clear
On Fri, 15 Jul 2005, David Gibson wrote:
> Well, the COW patch implements a fault handler, obviously. What
> specifically where you thinking about?
About a fault handler of course and about surrounding scalability issues.
I worked on some hugepage related patches last fall. Have you had a look
On Fri, 15 Jul 2005, David Gibson wrote:
> I'm still not at all sure what you're getting at. Do you mean the
> demand-allocation patches which were floating around at some point - I
> gather they're important for doing sensible NUMA allocation of
> hugepages. They have a small overlap with the C
On Fri, 15 Jul 2005, Paul Jakma wrote:
> On Thu, 14 Jul 2005, Christoph Lameter wrote:
>
> > Linux can already provide a response time within < 3 usecs from user space
> > using f.e. the Altix RTC driver which can generate an interrupt that then
> > sends a signal t
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > a clean way. It cannot even deliver the functionality it was designed to
> > deliver (see BIND).
>
> That seems like a unfair description to me. While things are not
> perfect they are definitely not as bad as you're trying to paint them.
Sorry this wen
On Thu, 4 Aug 2005, Richard Purdie wrote:
> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the failure
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > Address space migration? That is something new in this discussion. So
> > could you explain what you mean by that? I have looked at page migration
> > in a variety of contexts and could not see much difference.
>
> MCE page migration just puts a physica
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > Unless I am missing something, the call to follow_hugetlb_page() in
> > get_user_pages() is just an optimization. Removing it means
> > follow_page() will be called individually for each PAGE_SIZE page in the
> > huge page. We can probably do better but
On Fri, 5 Aug 2005, Stephen Pollei wrote:
> > On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> > > > This would imply a similiar kmalloc() would be useful as well.
> > > > Second, how relevant is it for the kernel?
> > > we've had a non-negliable amount of security holes because of this
> > So why do
On Mon, 8 Aug 2005, Pavel Machek wrote:
> Hi!
>
> > Got a new suspend patchsset at
> >
> > ftp://ftp.kernel.org:/pub/linux/kernel/people/christoph/suspend/2.6.13-rc4-mm1
> >
> > Check the series file for the sequence of patches.
>
> Something still goes very wrong after first resume. It seems
On Sun, 7 Aug 2005, Richard Purdie wrote:
> > > We know the the failure case can be identified by the
> > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > patch to dump useful debugging information when that occurs?
>
> Ok, this results in an infinite loop of one me
On Mon, 8 Aug 2005, Russell King wrote:
> ARM doesn't have cmpxchg nor does it have hardware access nor dirty
> bits. They're simulated in software.
Even the cmpxchg is simulated.
> What's the problem you're trying to solve?
A hang when starting X on ARM with rc4-mm1 which contains the page fa
e8 8e e0 ff ff 8b 55 ec 89 10 89 fa 8b 45 00
8b 58 04 89 f0 e8 5a e0 ff ff 89 fa 89 18 8b 45 00 8b 00 <8b> 58 04 89 f0 e8 27
e0 ff ff 89 18 8b 46 18 e9 d7 fe ff ff 89
<0>Kernel panic - not syncing: Attempted to kill the idle task!
Signed-off-by: Christoph Lameter <[EMAIL PRO
ew_entry is used for the new pte entry. handle_mm_fault must dirty
new_entry and not "entry". entry is only used for comparison. The current
version does not set the dirty bit.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: l
On Tue, 9 Aug 2005, Nigel Cunningham wrote:
> Just to let you know that I have it working with Suspend2. One thing I
> am concerned about is that we still need a way of determining whether a
> process has been signalled but not yet frozen. At the moment you just
> check p->todo, but if/when other
On Tue, 9 Aug 2005, Petr Vandrovec wrote:
> Problem is that pci_dev may be NULL - and it is NULL for example with
> kernel I've just built, with amd IDE driver built as a module while with
> ide-disk built into the kernel.
Yes that was discussed extensively by Andi and me and finally fixed by
On Tue, 9 Aug 2005, Nigel Cunningham wrote:
> > No it wont. A process that has notifications to process should do that
> > before being put into the freezer. Only after the notification list is
> > empty will the process be notified and as long as the notification is
> > pending no second notif
1. Move hwif_to_node to ide.h
2. Use hwif_to_node in ide-disk.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/ide/ide-disk.c
===
--- linux-2.6.orig/drivers/ide/ide-disk.c 2005-07-27 18:29:17.0
On Wed, 10 Aug 2005, Geert Uytterhoeven wrote:
> On Tue, 9 Aug 2005, Linux Kernel Mailing List wrote:
> > tree 518f62158f0923573decb8f072ac7282fb7575cb
> > parent aeb3f76350e78aba90653b563de6677b442d21d6
> > author Christoph Lameter <[EMAIL PROTECTED]> Wed,
On Wed, 10 Aug 2005, Bartlomiej Zolnierkiewicz wrote:
> hwif can't be NULL or something is *really* wrong
Ahh.. Yes Not enough time to think about this email properly since I
need to get to the LWCE in SF. Wrong description. The oops was caused by
pci_dev being NULL..
-
To unsubscribe from
On Wed, 10 Aug 2005, Alan Cox wrote:
> On Maw, 2005-08-09 at 19:59 -0700, Christoph Lameter wrote:
> > Yes you are right there is one additional place where pcibus_to_node is
> > used with the hwif that we did not cover. This better go into 2.6.13.
>
> drive->hwif is
sure
that we are all on the same page on this patch now:
---
From: Christoph Lameter <[EMAIL PROTECTED]>
There is one additional place where pcibus_to_node is used with the hwif
that we did not cover.
- Move hwif_to_node to ide.h
- Use hwif_to_node in ide-disk.c
Signed-off-by: Christ
On Tue, 16 Aug 2005, jerome lacoste wrote:
> Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme
> AX 300 SE/t mainboard.
>
> I remember seeing a message in the boot saying something along:
>
> "cannot connect to hardware clock."
>
> And now I see that the time is changing
t would duplicate code using a continuous timesource
> use a common code base.
Thats great!
> Think of it more as a replacement for the time_interpolator code (which
> thanks to Christoph Lameter, it is quite influenced by).
I have no objection to replacing the time_interpolator cod
On Tue, 16 Aug 2005, john stultz wrote:
> This is basically what I do in my patch. I directly apply the NTP
> adjustment to the timesource interval, and periodically increment the
> NTP state machine by the timesource interval when we accumulate it.
Is there some way to tell the NTP code how much
On Tue, 16 Aug 2005, john stultz wrote:
> That is why I'm suggesting time_interpolator users to move to my code
> (when they're ready, of course :).
Both are basically timesources. That is why I would suggest you upgrade
the interpolators to timesources. Doing that would enable a gradual
transi
On Wed, 17 Aug 2005, Ulrich Windl wrote:
> whatever the implementation is, at some point there must exist an interface
> go get
> and set "normal time", free of any jumps and jitter. That "frontend time"
> will be
> used a a base of correction. Basically that means time should be as monotonic
On Wed, 17 Aug 2005, vamsi krishna wrote:
> Seems like most of core size(VmSize) on ipf (126MB) is coming from the
> code size(VmExe) i.e 97MB. While the code size is just 62MB on amd64.
>
> Looks like IA-64 wastes a lot of VM due to big instruction sizes, so
> big instruction sizes will improve
On Wed, 6 Jul 2005, Anton Blanchard wrote:
> FYI the kernel has NUMA enabled but the machine has only 1 NUMA node.
Ummm. But it has multiple memory nodes? We ran into trouble with the funky
memory arrangement before.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Wed, 6 Jul 2005, Anton Blanchard wrote:
> Its a shared processor partition (meaning the partition can get
> scheduled anywhere), so we throw all the cpus and memory into node 0.
>
> This machine only has 1 cpu (2 threads) and they are both in node0:
>
> # ls -l /sys/devices/system/node/node0/
On Wed, 6 Jul 2005, Anton Blanchard wrote:
> Its using the default. Looking at include/asm-generic/topology.h:
>
> #ifndef pcibus_to_node
> #define pcibus_to_node(node)(-1)
> #endif
>
> I wonder what kmalloc_node does when you pass it -1.
That is the issue. It should fall back to kmalloc. O
On Wed, 6 Jul 2005, Anton Blanchard wrote:
>
> > That is the issue. It should fall back to kmalloc. One piece of the
> > patchset dropped out between Andrew and Linus.
>
> That helped, but I still had lots of free memory in the request_queue
> slab. Giving kmem_cache_alloc_node the same treatm
On Wed, 6 Jul 2005, Andi Kleen wrote:
> > That depends on the architecture. Some do round robin allocs for periods
> > of time during bootup. I think it is better to explicitly place control
>
> slab will usually do the right thing because it has a forced
> local node policy, but __gfp might no
On Wed, 6 Jul 2005, Andi Kleen wrote:
> > GFP allocs may not do the right thing. If you want to do this then it
> > may be best to set the memory policy to restrict allocations to the node
> > on which the device resides.
>
> They will do the right thing. Under memory pressue on the node
> it
On Wed, 6 Jul 2005, Andi Kleen wrote:
> > > Patching every driver in existence? That sounds like a lot of
> > > work.
> >
> > No just patch those that would benefit from it. The existing
>
> This would be "all devices that SGI ships on Altixes" ?
Anyone can patch devices drivers. High perform
On Wed, 6 Jul 2005, Andi Kleen wrote:
> On Wed, Jul 06, 2005 at 09:34:28AM -0700, Christoph Lameter wrote:
> > On Wed, 6 Jul 2005, Andi Kleen wrote:
> >
> > > - q = blk_init_queue_node(do_ide_request, &ide_lock,
> > > - pci
On Wed, 6 Jul 2005, Andi Kleen wrote:
> On Wed, Jul 06, 2005 at 09:35:32AM -0700, Christoph Lameter wrote:
> > On Wed, 6 Jul 2005, Andi Kleen wrote:
> >
> > > Instead of adding messy kmalloc_node()s everywhere run the
> > > PCI driver probe on the node local to
On Wed, 6 Jul 2005, Andi Kleen wrote:
> - q = blk_init_queue_node(do_ide_request, &ide_lock,
> - pcibus_to_node(drive->hwif->pci_dev->bus));
> + int node = 0; /* Should be -1 */
Why is this not -1?
> + int node = 0;
> + if (hwif->drive
On Wed, 6 Jul 2005, Andi Kleen wrote:
> Instead of adding messy kmalloc_node()s everywhere run the
> PCI driver probe on the node local to the device.
> Then the normal NUMA aware allocators do the right thing.
That depends on the architecture. Some do round robin allocs for periods
of time dur
if it was not able to determine
on which node a pcibus is located. For that case kmalloc_node must
work like kmalloc.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc2/mm/slab.c
===
--- linux-2.6.13-
On Thu, 7 Jul 2005, Andi Kleen wrote:
> > The slab allocator will do the right thing with the numa slab allocator in
> > Andrew's tree but not with the one in Linus'tree. The one is Linus tree
> > will just pickup whatever slab is available irregardless of the node.
>
> It should usually do the
t for the hwif != NULL and
test for pci_dev != NULL before determining the node number of the pci
bus that the device is connected to. Maybe we need a hwif_to_node for ide
drivers that is also able to determine the locality of other hardware?
Signed-off-by: Christoph Lameter <[EMAIL PROTECTE
On Thu, 7 Jul 2005, Andi Kleen wrote:
> On Thu, Jul 07, 2005 at 09:21:55AM -0700, Christoph Lameter wrote:
> > On Wed, 6 Jul 2005, Andi Kleen wrote:
> >
> > > Without this patch a dual Xeon EM64T machine would oops on boot
> > > because the hwif pointer here w
On Thu, 7 Jul 2005, Andi Kleen wrote:
> > node = -1 if the node cannot be determined.
>
> But that will crash right now.
That was fixed. Have a look at the git logs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
On Thu, 7 Jul 2005, Linus Torvalds wrote:
> If you make it use a trivial inline function for the thing, I think that
> would be ok, though.
Like this?
Index: linux-2.6.git/drivers/ide/ide-probe.c
===
--- linux-2.6.git.orig/drivers/
On Thu, 7 Jul 2005, Linus Torvalds wrote:
> Yes. Except that if hwif is NULL, we'll have other oopses since we access
> that in other places.
>
> Why _is_ hwif NULL anyway? That's another, unrelated thing, and should
> probably have a separate check and an early return.
I was wondering about t
On Thu, 7 Jul 2005, Andi Kleen wrote:
> > > The setup was a Intel board with 1 PATA/4 SATA onboard and only a CD-ROM
> > > and a external Promise PATA controller with two PATA disks.
> >
> > actual OOPS would be very useful
>
> It's difficult because I don't have serial on that machine.
Maybe w
On Fri, 9 Jul 2005, Andi Kleen wrote:
> I think that is a really really bad idea. slab is already complex enough
> and adding scary hacks like this will probably make it collapse
> under its own weight at some point.
Seconded.
Maybe we can solve this by bringing the system up in a limited
con
On Wed, 27 Jul 2005, Andrew Morton wrote:
> > return objp;
> > }
> > -EXPORT_SYMBOL(kmem_cache_alloc_node);
> >
> > #endif
>
> Even though we don't currently have in-module users, we probably will do so
> soon and it's a part of the slab API and the slab API is exported to
> modules. I d
On Wed, 27 Jul 2005, Adrian Bunk wrote:
> > I fully agree. Drivers will have to use that call in the future in order
> > to properly place their control structures. The e1000 in your tree already
> > does so and may be compiled as a module. Thus applying this patch will
> > break mm.
>
> I don
Hmmm. I am thinking about an alternative to PF_FREEZE and TIF_FREEZE.
PF/TIF_FREEZE essentially makes a task call a certain function in the
context of the task. Maybe there is a way to generalize that?
One could introducing a notifier chain (todo) in the task_struct that
is then called in the c
On Thu, 28 Jul 2005, Pavel Machek wrote:
> > process. It may also allow changing values that so far cannot be
> > changed from the outside in the task struct by running a function
> > in the context of the process.
>
> Well, we really need slightly more from "running in process context":
> we als
On Thu, 28 Jul 2005, Adrian Bunk wrote:
> What is the oldest gcc we want to support in kernel 2.6?
>
> Currently, it's 2.95 .
>
> I'd suggest raising this to 3.2 which should AFAIK not be a problem for
> any distribution supporting kernel 2.6 .
You have all my support for this. Some weird macr
On Thu, 28 Jul 2005, Andrew Morton wrote:
> I remain fairly dubious about this - it seems a fairly specific and
> complex piece of work to speed up one extremely specific part of one type of
> computer's one type of workload. Surely there's a better way :(
The patches provide the basis fo
On Thu, 28 Jul 2005, Pavel Machek wrote:
> > > I guess I'd prefer if you left "refrigerator()" and "try_to_freeze()"
> > > functions in; there are about 1000 drivers that know/use them, and
> > > some patches are probably in the queue
> >
> > Yeah but then other uses also could benefit from t
.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/kernel/sys.c
===
--- linux-2.6.13-rc3.orig/kernel/sys.c 2005-07-12 21:46:46.0 -0700
+++ linux-2.6.13-rc3/kernel/sys.c 2005-07-28
the logic is local to the
suspend code and no longer requires changes to other kernel components.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/include/linux/sched.h
===
--- linux-2.6.13-rc3.orig/i
suspend).
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/include/linux/sched.h
===
--- linux-2.6.13-rc3.orig/include/linux/sched.h 2005-07-12 21:46:46.0
-0700
+++ linux-2.6.13-rc3/include
by macros in
include/linux/sched.h.
At some point--when all drivers have been changed--the macros in
include/linux/sched.h
may be removed.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3/drivers/
On Thu, 28 Jul 2005, Russell King wrote:
> ARM can't support atomic page table operations as such - the Linux view
> of the page table is separate from the hardware view, and there's some
> CPU specific code which translates from the Linux view to the hardware
> view.
Yes. The patches fall back t
On Thu, 28 Jul 2005, Pavel Machek wrote:
> Hi!
>
> > > Introduce a todo notifier in the task_struct so that a task can be told
> > > to do
> > > certain things. Abuse the suspend hooks try_to_freeze, freezing and
> > > refrigerator
> > > to establish checkpoints where the todo list is processed
On Fri, 29 Jul 2005, Pavel Machek wrote:
> > Dont fix it up. Remove the ealier patch.
>
> Oops. Do you happen to have patch relative to -mm or something? I'd
> prefer not to mess it up second time...
Ok. I will make a patch against mm tomorrow. Patches
are typically against Linus latest and if
On Thu, 28 Jul 2005, Andrew Morton wrote:
> Well if you want to go this way I can just drop the TIF_FREEZE stuff and
> use the patches-relative-to-mainline.
I would appreciate that.\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
This patch adds two new functions to mm/mempolicy.c that allow the conversion
of a memorypolicy to a textual representation and vice versa.
The patch provides necessary functions for the merging of numa_maps into
smap.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-
This patch merges the functionality provided by the numa_maps patch in mm
into the /proc//smaps facility. The numa_maps patch may then be
dropped from mm.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3-mm3/fs/proc/task
Maybe we should rename smaps to emaps? After all they include more
information than just sizes. So extended maps would be better.
Patch on top of mm and the numa_maps merge into smap.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3-mm3/fs/proc/
list
before the
notifier call.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3-mm3/kernel/sys.c
===
--- linux-2.6.13-rc3-mm3.orig/kernel/sys.c 2005-07-29 10:38:39.0
-0700
+++ linux-
What you are dealing with is a machine that is using ITC as a time bases.
That is a special case. The fix should not affect machines that have a
proper time source. More below. You can circumvent the compensation for
ITC inaccuracies by specifying "nojitter" on the kernel command if you are
wil
by macros in
include/linux/sched.h.
At some point--when all drivers have been changed--the macros in
include/linux/sched.h
may be removed.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3-mm3/drivers/
801 - 900 of 5044 matches
Mail list logo
