Andi Kleen wrote:
OK, so what is the alternative? Well, if we had a va_start and
va_end (or a va_start and length) we could move the shared object
once using a call of the form
migrate_pages(pid, va_start, va_end, count, old_node_list,
new_node_list);
with old_node_list = 0 1 2 ... 31
On Tue, Feb 22, 2005 at 12:45:21PM -0600, Ray Bryant wrote:
> Andi Kleen wrote:
>
> >
> >How about you add the va_start, va_end but only accept them
> >when pid is 0 (= current process). Otherwise enforce with EINVAL
> >that they are both 0. This way you could map the
> >shared object into the ba
Andi Kleen wrote:
How about you add the va_start, va_end but only accept them
when pid is 0 (= current process). Otherwise enforce with EINVAL
that they are both 0. This way you could map the
shared object into the batch manager, migrate it there, then
mark it somehow to not be migrated further, a
On Mon, Feb 21, 2005 at 11:12:14AM -0600, Ray Bryant wrote:
> Andi Kleen wrote:
>
>
> >
> >I wouldn't bother fixing up VMA policies.
> >
> >
>
> How would these policies get changed so that they represent the
> reality of the new node location(s) then? Doesn't this have to
> happen as part of
> OK, so what is the alternative? Well, if we had a va_start and
> va_end (or a va_start and length) we could move the shared object
> once using a call of the form
>
>migrate_pages(pid, va_start, va_end, count, old_node_list,
> new_node_list);
>
> with old_node_list = 0 1 2 ... 31
>
Andi,
Oops. It's late. The pargraph below in my previous note confused
cpus and nodes. It should have read as follows:
Let's suppose that nodes 0-1 of a 64 node [was: CPU] system have graphics
pipes. To keep it simple, we will assume that there are 2 cpus
per node like an Altix [128 CPUS in thi
Andi,
I went back and did some digging on one the issues that has dropped
off the list here: the case where the set of old nodes and new
nodes overlap in some way. No one could provide me with a specific
example, but the thread was that "This did happen in certain scenarios".
Part of these scenari
Andi Kleen wrote:
I wouldn't bother fixing up VMA policies.
How would these policies get changed so that they represent the
reality of the new node location(s) then? Doesn't this have to
happen as part of migrate_pages()?
--
Best Regards,
Ray
---
On Mon, Feb 21, 2005 at 02:42:16AM -0600, Ray Bryant wrote:
> All,
>
> Just an update on the idea of migrating a process without suspending
> it.
>
> The hard part of the problem here is to make sure that the page_migrate()
> system call sees all of the pages to migrate. If the process that is
>
Ray wrote:
> As I understood it, we were converging on the following:
> (1) ...
> (2) ...
> (3) ...
> This is different than your reply above, which seems to imply that:
> (A) ...
> (B) ...
Andi reacted to various details of (A) and (B).
Any chance, Andi, of you directly stating whethe
On Mon, Feb 21, 2005 at 01:29:41AM -0600, Ray Bryant wrote:
> This is different than your reply above, which seems to imply that:
>
> (A) Step 1 is to migrate mapped files using mbind(). I don't understand
> how to do this in general, because:
> (a) I don't know how to make a non-racy
All,
Just an update on the idea of migrating a process without suspending
it.
The hard part of the problem here is to make sure that the page_migrate()
system call sees all of the pages to migrate. If the process that is
being migrated can still allocate pages, then the page_migrate() call
may mis
Paul Jackson wrote:
You have to walk to full node mapping for each array, but
even with hundreds of nodes that should not be that costly
I presume if you knew that the job only had pages on certain nodes,
perhaps due to aggressive use of cpusets, that you would only have to
walk those nodes, right
Andi Kleen wrote:
Do you have any better way to suggest, Andi, for a batch manager to
relocate a job? The typical scenario, as Ray explained it to me, is
- Give the shared libraries and any other files a suitable policy
(by mapping them and applying mbind)
- Then execute migrate_pages() for the
Andi Kleen wrote:
But we are least at the level of agreeing that the new system
call looks something like the following:
migrate_pages(pid, count, old_list, new_list);
right?
For the external case probably yes. For internal (process does this
on its own address space) it should be hooked into mbin
> - Give the shared libraries and any other files a suitable policy
> (by mapping them and applying mbind)
Ah - I think you've said this before, and I'm being a bit retarded.
You're saying that one could horse around with the physical placement of
existing files mapped into another tasks space b
> Do you have any better way to suggest, Andi, for a batch manager to
> relocate a job? The typical scenario, as Ray explained it to me, is
- Give the shared libraries and any other files a suitable policy
(by mapping them and applying mbind)
- Then execute migrate_pages() for the anonymous pag
Andi wrote:
> I still think it's fundamentally unclean and racy. External processes
> shouldn't mess with virtual addresses of other processes.
It's not really messing with (changing) the virtual addresses of
another process. It's messing with the physical placement. It's
using the virtual addre
> >Perhaps node masks would be better and teaching the kernel to handle
> >relative distances inside the masks transparently while migrating?
> >Not sure how complicated this would be to implement though.
> >
> >Supporting interleaving on the new nodes may be also useful, that would
> >need a polic
Andi Kleen wrote:
[Enjoy your vacation]
[I am thanks -- or I was -- I go home tomorrow]
I assume they would allow marking arbitary segments with specific
policies, so it should be possible.
An alternative way to handle shared libraries BTW would be to add the ELF
headers Steve did in his patch. And
Andi Kleen wrote:
You and Robin mentioned some problems with "double migration"
with that, but it's still not completely clear to me what
problem you're solving here. Perhaps that needs to be reexamined.
There is one other case where Robin and I have talked about double
migration. That is the cas
Andi, et al:
I see that several messages have been sent in the interim.
I apologize for being "out of sync", but today is my last
day to go skiing and it is gorgeous outside. I'll try
to catch up and digest everthing later.
--
---
Ray Bryant
512-453-967
Here's an interface proposal that may be a middle ground and
should satisfy both small and large system requirements:
The system call interface would be:
page_migrate(pid, va_start, va_end, count, old_node_list, new_node_list);
(e. g. same as before, but please keep reading):
The following rest
Andi wrote:
> Problem is what happens
> when some memory is in some other node due to memory pressure fallbacks.
> Your scheme would not migrate this memory at all.
The arrays of old and new nodes handle this fine.
Include that 'other node' in the array of old nodes,
and the corresponding new nod
Andi wrote:
> e.g. job runs threads on nodes 0,1,2,3 and you want it to move
> to nodes 4,5,6,7 with all memory staying staying in the same
> distance from the new CPUs as it were from the old CPUs, right?
>
> It explains why you want old_node, you would do
> (assuming node mask arguments)
Yu
Andi wrote:
> I don't like old_node* very much because it's imho unreliable
> (because you can usually never fully know on which nodes the old
> process was and there can be good reasons to just migrate everything)
That's one way that the arrays of old and new nodes pays off.
You can list any old
Andi - what does this line mean:
+ node mask length.
I guess its the names of the parameters in a proposed
migration system call. Length of what, mask of what,
what's the node mean, huh?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
[Enjoy your vacation]
On Fri, Feb 18, 2005 at 02:38:42AM -0600, Ray Bryant wrote:
>
> Let's start off with at least one thing we can agree on. If xattrs
> are already part of XFS, then it seems reasonable to use an extended
> attribute to mark certain files as non-migratable. (Some further
> t
Andi Kleen wrote:
[Sorry for the late answer.]
No problem, remember, I'm supposed to be on vacation, anyway. :-)
Let's start off with at least one thing we can agree on. If xattrs
are already part of XFS, then it seems reasonable to use an extended
attribute to mark certain files as non-migratabl
[Sorry for the late answer.]
On Tue, Feb 15, 2005 at 09:44:41PM -0600, Ray Bryant wrote:
> >
> >
> >Sorry, but the only real difference between your API and mbind is that
> >yours has a pid argument.
> >
>
> That may be true, but the internals of the implementations have got
> to be pretty diffe
Andi Kleen wrote:
Making memory migration a subset of page migration is not a general
solution. It only works for programs that are using memory policy
to control placement. As I've tried to point out multiple times
before, most programs that I am aware of use placement based on
first-touch. Wh
Thanks Andi for your effort to present your case more completely.
I agree that there is some 'talking by each other' going on.
Dave Hansen has publically (and Ray privately) sought to
move this discussion to linux-mm (or more specifically,
off lkml for now).
Any chance, Andi, that you could repos
Good explanation, Robin. Thanks.
See y'all on linux-mm.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "uns
On Wed, Feb 16, 2005 at 08:58:19AM +1100, Peter Chubb wrote:
> > "Robin" == Robin Holt <[EMAIL PROTECTED]> writes:
>
> Robin> On Tue, Feb 15, 2005 at 08:35:29AM -0800, Paul Jackson wrote:
> >> What about the suggestion I had that you sort of skipped over,
> >> which amounted to changing the sy
Dr Peter Chubb writes:
> Can page migration be done lazily, instead of all at once?
That might be a useful option. Not my area to comment on.
We would also require, at least as an option, to be able to force the
migration on demand. Some of our big honkin iron parallel jobs run with
a high degr
> Making memory migration a subset of page migration is not a general
> solution. It only works for programs that are using memory policy
> to control placement. As I've tried to point out multiple times
> before, most programs that I am aware of use placement based on
> first-touch. When we mi
In the interest of the size of everyone's inboxes, I mentioned to Ray
that we might move this discussion to a smaller forum while we resolve
some of the outstanding issues. Ray's going to post a followup to to
linux-mm, and trim the cc list down. So, if you're still interested,
keep your eyes on
On Tue, Feb 15, 2005 at 08:35:29AM -0800, Paul Jackson wrote:
> What about the suggestion I had that you sort of skipped over, which
> amounted to changing the system call from a node array to just one
> node:
>
> sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
>
> to:
>
Dave Hansen wrote:
On Tue, 2005-02-15 at 04:50 -0600, Robin Holt wrote:
What is the fundamental opposition to an array from from-to node mappings?
They are not that difficult to follow. They make the expensive traversal
of ptes the single pass operation. The time to scan the list of from nodes
to
Andi Kleen wrote:
[Sorry, didn't answer to everything in your mail the first time.
See previous mail for beginning]
On Mon, Feb 14, 2005 at 06:29:45PM -0600, Ray Bryant wrote:
migrating, and figure out from that what portions of which pid's
address spaces need to migrated so that we satisfy the c
On Tue, 2005-02-15 at 04:50 -0600, Robin Holt wrote:
> What is the fundamental opposition to an array from from-to node mappings?
> They are not that difficult to follow. They make the expensive traversal
> of ptes the single pass operation. The time to scan the list of from nodes
> to locate the
> I really don't see how that is relevant to the current discussion, which,
> as AFAIK, is that the kernel interface should be "migrate an entire process"
> versus what I have proposed. What we are trying to avoid here for shared
> libraries is two things: (1) don't migrate them needlessly, and (
Andi Kleen wrote:
(1) You really don't want to migrate the code pages of shared libraries
that are mapped into the process address space. This causes a
useless shuffling of pages which really doesn't help system
performance. On the other hand, if a shared library is some
private
Robin Holt wrote:
On Mon, Feb 14, 2005 at 06:29:45PM -0600, Ray Bryant wrote:
which is what you are asking for, I think. The library's job
(in addition to suspending all of the processes in the list for
the duration of the migration operation, plus do some other things
that are specific to sn2 har
Robin wrote:
> That seems like it is insane!
Thank-you, thank-you.
What about the suggestion I had that you sort of skipped over, which
amounted to changing the system call from a node array to just one
node:
sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
to:
s
On Tue, Feb 15, 2005 at 07:49:06AM -0800, Paul Jackson wrote:
> Robin wrote:
> > Then how do you handle overlapping nodes. If I am doing a 5->4, 4->3,
> > 3->2, 2->1 shift ...
>
> Then do the shifts in the other order, first 2->1, then 3->2, ...
>
> So now you ask, what if you are doing a rotati
Robin wrote:
> Then how do you handle overlapping nodes. If I am doing a 5->4, 4->3,
> 3->2, 2->1 shift ...
Then do the shifts in the other order, first 2->1, then 3->2, ...
So now you ask, what if you are doing a rotation? Use a temporary
node: 2->tmp, 3->2, ..., N->(N-1), tmp->N.
So now you
Robin wrote:
> Requiring that the process is stopped will somewhat limit the use of
> this API outside of the HPC space where so much control can be had over
> the processes.
Good point. Hopefully we can find a way to design this system
call so that it does not require suspension. Some uses of
Robin wrote:
> Given that the first user of this may place in onto a 256 node system,
> the chances that they use the same node in the source and destination node
> array are very good.
Am I parsing this sentence correctly when I read it as stating that we
need to handle the case where the source
Ray wrote:
> The exact ordering of when a task is moved to a new cpuset and when the
> migration occurs doesn't matter, AFAIK, if we accept the notion that
> a migrated task is in suspended state until after everything associated
> with it (including the new cpuset definition) is done.
The existan
Would it work to have the migration system call take exactly two node
numbers, the old and the new? Have it migrate all pages in the address
space specified that are on the old node to the new node. Leave any
other pages alone. For one thing, this avoids passing a long list of
nodes, for an N-wa
Robin wrote:
> for the second process and then from node 8 to node 4 for the second.
"for the second ... for the second"
I couldn't make sense of this statement. Should one of those
seconds be a first; what word(s) are elided after the second
"second"?
--
I won't rest till it
On Tue, Feb 15, 2005 at 12:53:03PM +0100, Andi Kleen wrote:
> > (2) You really only want to migrate pages once. If a file is mapped
> > into several of the pid's that are being migrated, then you want
> > to figure this out and issue one call to have it moved wrt one of
> > the pid
[Sorry, didn't answer to everything in your mail the first time.
See previous mail for beginning]
On Mon, Feb 14, 2005 at 06:29:45PM -0600, Ray Bryant wrote:
> migrating, and figure out from that what portions of which pid's
> address spaces need to migrated so that we satisfy the constraints
> g
> (1) You really don't want to migrate the code pages of shared libraries
> that are mapped into the process address space. This causes a
> useless shuffling of pages which really doesn't help system
> performance. On the other hand, if a shared library is some
> private thin
On Mon, Feb 14, 2005 at 06:29:45PM -0600, Ray Bryant wrote:
> which is what you are asking for, I think. The library's job
> (in addition to suspending all of the processes in the list for
> the duration of the migration operation, plus do some other things
> that are specific to sn2 hardware) wou
On Mon, Feb 14, 2005 at 02:22:54PM -0800, Dave Hansen wrote:
> On Mon, 2005-02-14 at 16:01 -0600, Robin Holt wrote:
> > On Mon, Feb 14, 2005 at 10:50:42AM -0800, Dave Hansen wrote:
> > > On Mon, 2005-02-14 at 07:52 -0600, Robin Holt wrote:
> > > > The node mask is a list of allowed. This is intend
Paul Jackson wrote:
Ray wrote:
[Thus the disclaimer in
the overview note that we have figured all the interaction with
memory policy stuff yet.]
Does the same disclaimer apply to cpusets?
Unless it causes some undo pain, I would think that page migration
should _not_ violate a tasks cpuset. I gue
Ray wrote:
> [Thus the disclaimer in
> the overview note that we have figured all the interaction with
> memory policy stuff yet.]
Does the same disclaimer apply to cpusets?
Unless it causes some undo pain, I would think that page migration
should _not_ violate a tasks cpuset. I guess this means
Andi Kleen wrote:
For our use, the batch scheduler will give an intermediary program a
list of processes and a series of from-to node pairs. That process would
then ensure all the processes are stopped, scan their VMAs to determine
what regions are mapped by more than one process, which are mapped
Andi Kleen wrote:
Ray Bryant <[EMAIL PROTECTED]> writes:
set of pages associated with a particular process need to be moved.
The kernel interface that we are proposing is the following:
page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
[Only commenting on the interface, haven't rea
Andi Kleen wrote:
But how do you use mbind() to change the memory placement for an anonymous
private mapping used by a vendor provided executable with mbind()?
For that you use set_mempolicy.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [EMAIL PROTECTED] For
On Mon, 2005-02-14 at 16:01 -0600, Robin Holt wrote:
> On Mon, Feb 14, 2005 at 10:50:42AM -0800, Dave Hansen wrote:
> > On Mon, 2005-02-14 at 07:52 -0600, Robin Holt wrote:
> > > The node mask is a list of allowed. This is intended to be as near
> > > to a one-to-one migration path as possible.
>
On Mon, Feb 14, 2005 at 10:50:42AM -0800, Dave Hansen wrote:
> On Mon, 2005-02-14 at 07:52 -0600, Robin Holt wrote:
> > The node mask is a list of allowed. This is intended to be as near
> > to a one-to-one migration path as possible.
>
> If that's the case, it would make the kernel internals a b
> For our use, the batch scheduler will give an intermediary program a
> list of processes and a series of from-to node pairs. That process would
> then ensure all the processes are stopped, scan their VMAs to determine
> what regions are mapped by more than one process, which are mapped
> by addi
> But how do you use mbind() to change the memory placement for an anonymous
> private mapping used by a vendor provided executable with mbind()?
For that you use set_mempolicy.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
On Mon, 2005-02-14 at 07:52 -0600, Robin Holt wrote:
> The node mask is a list of allowed. This is intended to be as near
> to a one-to-one migration path as possible.
If that's the case, it would make the kernel internals a bit simpler to
only take a "from" and "to" node, instead of those maps.
On Sat, Feb 12, 2005 at 10:29:14PM +0100, Andi Kleen wrote:
> On Sat, Feb 12, 2005 at 01:54:26PM -0200, Marcelo Tosatti wrote:
> > On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> > > Ray Bryant <[EMAIL PROTECTED]> writes:
> > > > set of pages associated with a particular process need
On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> Ray Bryant <[EMAIL PROTECTED]> writes:
> > set of pages associated with a particular process need to be moved.
> > The kernel interface that we are proposing is the following:
> >
> > page_migrate(pid, va_start, va_end, count, old_nodes,
On Sat, Feb 12, 2005 at 01:04:22PM -0800, Dave Hansen wrote:
> On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> > This patch introduces the sys_page_migrate() system call:
> >
> > sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> >
> > Its intent is to cause the pages
Dave wrote:
> Might it be useful to use nodemasks instead of those arrays?
I don't think he can. A nodemask represents an unorderd set of nodes.
He needs (or wants) to pass a map, mapping the node that each
page might be on, to the node to which it should migrate. A bitmask
doesn't contain eno
On Sat, Feb 12, 2005 at 01:54:26PM -0200, Marcelo Tosatti wrote:
> On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> > Ray Bryant <[EMAIL PROTECTED]> writes:
> > > set of pages associated with a particular process need to be moved.
> > > The kernel interface that we are proposing is the
On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> This patch introduces the sys_page_migrate() system call:
>
> sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
>
> Its intent is to cause the pages in the range given that are found on
> old_nodes[i] to be moved to new_no
Andi wrote:
> They're already exposed through mbind/set_mempolicy/get_mempolicy and sysfs
> of course.
And soon I hope through cpusets ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1
On Sat, Feb 12, 2005 at 01:54:26PM -0200, Marcelo Tosatti wrote:
> On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> > Ray Bryant <[EMAIL PROTECTED]> writes:
> > > set of pages associated with a particular process need to be moved.
> > > The kernel interface that we are proposing is the
On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> Ray Bryant <[EMAIL PROTECTED]> writes:
> > set of pages associated with a particular process need to be moved.
> > The kernel interface that we are proposing is the following:
> >
> > page_migrate(pid, va_start, va_end, count, old_nodes,
On Sat, Feb 12, 2005 at 07:34:32AM -0500, Arjan van de Ven wrote:
> On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> > This patch introduces the sys_page_migrate() system call:
> >
> > sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
>
> are you really sure you want to
On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> This patch introduces the sys_page_migrate() system call:
>
> sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
are you really sure you want to expose nodes to userspace via an ABI
this solid and never changing? To me that
Ray Bryant <[EMAIL PROTECTED]> writes:
> set of pages associated with a particular process need to be moved.
> The kernel interface that we are proposing is the following:
>
> page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
[Only commenting on the interface, haven't read your pat
Minor comments ... nothing profound.
Ray wrote:
> once we agree on what the authority model should be.
Are the usual kill-like permissions sufficient?
You can migrate the pages of a process if you can kill it.
===
In the following routine, tighten up some vertical spacing,
add { ... } , ...
Th
d files, shared
anonymouse storage, and shared segments.
Signed-off-by:Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/arch/ia64/kernel/entry.S
===
--- linux-2.6.11-rc2-mm2.orig/arch/ia64/kernel/entry.S 2005
Add some extern declarations to include/linux/mmigrate.h to
eliminate some "implicitly" declared warnings.
Signed-off-by:Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h
===
---
x27;t care where
we migrate the page, just migrate it out of here) or
the system is not a NUMA system.
Signed-off-by:Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h
===
--- linux-2.6.11-rc2-mm2.o
Fix up a switch statement so gcc doesn't complain about it.
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux/mm/mmigrate.c
===
--- linux.orig/mm/mmigrate.c2005-01-30 11:13:58.0 -0800
+++ linux/mm/mmigrate.c 2005
This patch removes some remaining Memory HOTPLUG specific code
from the page migration patch. I have sent Dave Hansen the -R
version of this patch so that this code can be added back
later at the start of the Memory HOTPLUG patches themselves.
In particular, this patchremoves VM_IMMOVABLE and MA
following and in the descriptions of the other patches, we will
refer to the page migration patch and to the Memory Hotplug patch itself
-- by this we mean the patches available as, for example:
patch-2.6.11-rc2-mm3-mhp1-pm.gz
and the rest of the hotplug patches available in
broken-out-2.6.11-
Fix a trivial error in include/linux/mmigrate.h
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/include/linux/mmigrate.h
===
--- linux-2.6.11-rc2-mm2.orig/include/linux/mmigrate.h 2005-02-11
CONFIG_MEMORY_HOTPLUG
code from the page migration patch.
Signed-off-by: Ray Bryant <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/mm/vmalloc.c
===
--- linux-2.6.11-rc2-mm2.orig/mm/vmalloc.c 2005-02-11 10:08:10.0
> >
> > >
> > > Begin forwarded message:
> > >
> > > Date: Sun, 30 Jan 2005 15:45:04 -0500
> > > From: Paul Blazejowski <[EMAIL PROTECTED]>
> > > To: Andrew Morton <[EMAIL PROTECTED]>
> > > Cc: LKML
> > > Subject: Re
Hi Ralf,
On Thu, 3 Feb 2005 13:37:15 +0100
Ralf Baechle <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 31, 2005 at 07:46:18AM +0900, Yoichi Yuasa wrote:
>
> > This patch adds iomap functions to MIPS system.
>
> And it still only works for a single PCI bus.
Which boards are there a problem?
ocelot-c
On Mon, Jan 31, 2005 at 07:46:18AM +0900, Yoichi Yuasa wrote:
> This patch adds iomap functions to MIPS system.
And it still only works for a single PCI bus.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
"Randy.Dunlap" <[EMAIL PROTECTED]> writes:
> Vivek Goyal wrote:
> > Hi Andrew,
> > This patch has been generated against 2.6.11-rc2-mm2. This fixes a very
> > minor bug in kexec.
>
> Have you run sparse on a kexec-patched kernel tree?
> I have
Vivek Goyal wrote:
Hi Andrew,
This patch has been generated against 2.6.11-rc2-mm2. This fixes a very
minor bug in kexec.
Have you run sparse on a kexec-patched kernel tree?
I have, but not lately. It needed some s/0/NULL/ in several places,
but that was before the latest big changes...
diff -puN
Hi Andrew,
This patch has been generated against 2.6.11-rc2-mm2. This fixes a very
minor bug in kexec.
Thanks
Vivek
This patch fixes a minor bug in kexec. Changing the data type of flags makes
sure proper control flow of code during crash event.
Signed-off-by: Vivek Goyal <[EMAIL PROTEC
Zhonglin Zhang <[EMAIL PROTECTED]> wrote:
>
> Hi, Andrew
>
> Could you please check it ? I have worked out my little patch to fix
> it. But not any feedback. Is it ok in your machine which is not-SMP?
>
--- 25/include/linux/stop_machine.h~fix-kallsyms-insmod-rmmod-race-fix-fix-fix
2005-0
On Tue, 2005-02-01 at 22:42 -0500, Joseph Fannin wrote:
> On Tue, Feb 01, 2005 at 10:18:33AM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2005-01-31 at 06:21 -0500, Joseph Fannin wrote:
> >
> > > I'm getting a blank screen with radeonfb on two boxes here as
> > > well. One is a beige g3, t
On Tue, Feb 01, 2005 at 10:18:33AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-01-31 at 06:21 -0500, Joseph Fannin wrote:
>
> > I'm getting a blank screen with radeonfb on two boxes here as
> > well. One is a beige g3, the other is i386; both have PCI Radeon 7000s
> > with radeonfb non
Hi, Andrew
Could you please check it ? I have worked out my little patch to fix
it. But not any feedback. Is it ok in your machine which is not-SMP?
Regards
--
Zhonglin Zhang <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
=
Oops: 0002 [#1]
PREEMPT
Modules linked in: tulip
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010092 (2.6.11-rc2-mm2)
EIP is at dequeue_task+0x14/0x70
eax: c0414ba0 ebx: c0414b80 ecx: c0414b80 edx:
esi: edi: 0086 ebp: c04e3e10 esp: c04e3e08
ds: 007b
On Mon, 31 Jan 2005 22:46:12 +0100, Laurent Riffard
<[EMAIL PROTECTED]> wrote:
> Le 31.01.2005 22:15, Andre Eisenbach a écrit :
> > My PCMCIA slot (yenta_socket) doesn't work anymore with
> > 2.6.11-rc2-m2. See the dmesg output below. It works fine with
> > 2.6.11-rc1-mm1.
>
> I had the same type
1 - 100 of 147 matches
Mail list logo
