Serge E. Hallyn wrote:
>
> But note that in either case we need to deal with a bunch of locking.
> So getting back to Pierre's patchset, IIRC 1-8 are cleanups worth
> doing no matter 1. 9-11 sound like they are contentuous until
> we decide whether we want to go with a create_with_id() type app
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
>
> Serge E. Hallyn wrote:
>> Quoting Oren Laadan ([EMAIL PROTECTED]):
>>> I strongly second Kirill on this matter.
>>>
>>> IMHO, we should _avoid_ as much as possible exposing internal kernel
>>> state to applications, unless a _real_ need for it is _clea
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
Lee wrote:
> Also, your cpuset/mempolicy work will probably need to undo the
> unconditional masking in contextualize_policy() and/or save the original
> node mask somewhere...
Yeah, something like that ... just a small matter of code.
--
I won't rest till it's the best ...
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> The patch I just posted doesn't depend on the numactl changes and seems
> quite minimal to me. I think it cleans up the differences between
> set_mempolicy() and mbind(), as well. However, some may take exception
> to the change in behavior--silently
On Tue, 2008-02-05 at 15:33 -0600, Paul Jackson wrote:
> David wrote:
> > It would be disappointing to see a lot of work done to fix
>
> The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
>
> I continue to prefer not to hijack this thread for that other discussion.
> Jus
David wrote:
> It would be disappointing to see a lot of work done to fix
The suggested patch of KOSAKI Motohiro didn't look like a lot of work to me.
I continue to prefer not to hijack this thread for that other discussion.
Just presenting your position and calling it "simple" is misleading.
The
On Tue, 5 Feb 2008, Paul Jackson wrote:
> David wrote:
> > The more alarming result of these remaps is in the MPOL_BIND case, as
> > we've talked about before. The language in set_mempolicy(2):
>
> You're diving into the middle of a rather involved discussion
> we had on the other various patch
David wrote:
> The more alarming result of these remaps is in the MPOL_BIND case, as
> we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches proposed to extend the
interaction of mempolicy's
On Tue, 5 Feb 2008, Paul Jackson wrote:
> Since any of those future patches only add optional modes
> with new flags, while preserving current behaviour if you
> don't use one of the new flags, therefore the current behavior
> has to work as best it can.
>
There's a subtlety to this issue that a
On Tue, 5 Feb 2008, Paul Jackson wrote:
> But that discussion touched on some other long standing deficiencies
> in the way that I had originally glued cpusets and memory policies
> together. The current mechanism doesn't handle changing cpusets very
> well, especially if the number of nodes in t
Christoph wrote:
> Can we fix up his patch to address the immediate issue?
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
Therefore fixes
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
> Christoph: you are free to ignore any part of this discussion that you
> wish...
Had the impression that we are ignoring Kosaki's fix to the problem. Can
we fix up his patch to address the immediate issue?
--
To unsubscribe from this list: send the
Quoting Oren Laadan ([EMAIL PROTECTED]):
>
> I strongly second Kirill on this matter.
>
> IMHO, we should _avoid_ as much as possible exposing internal kernel
> state to applications, unless a _real_ need for it is _clearly_
> demonstrated. The reasons for this are quite obvious.
Hmm, sure, but th
On Tue, 2008-02-05 at 10:12 -0800, Christoph Lameter wrote:
> Could we focus on the problem instead of discussion of new patches under
> development?
Christoph: you are free to ignore any part of this discussion that you
wish...
> Can we confirm that what Kosaki sees is a bug?
by definition,
Could we focus on the problem instead of discussion of new patches under
development? Can we confirm that what Kosaki sees is a bug?
--
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.o
On Tue, 2008-02-05 at 04:51 -0500, Oren Laadan wrote:
> That said, I suggest the following method instead (this is the method
> we use in Zap to determine the desired resource identifier when a new
> resource is allocated; I recall that we had discussed it in the past,
> perhaps the mini-summit in
On Tue, 2008-02-05 at 14:31 +, Mel Gorman wrote:
> On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > > When the kernel behaviour changes and breaks user space then the kernel
> > > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
> >
> > The memoryless nodes patch
On (04/02/08 13:20), Lee Schermerhorn didst pronounce:
> > > When the kernel behaviour changes and breaks user space then the kernel
> > > is usually wrong. Cc'ed Lee S. who maintains the kernel code now.
>
> The memoryless nodes patch series changed a lot of things, so just
> reverting this one a
Andrew Morton wrote:
> On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
[snip]
> argh, I'd forgotten about that. You bisected it down to a clearly-innocent
> patch and none of the mm developers appeared interested.
>
> Oh well, it'll probably be in mainline tomorr
Hi Paul
> Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Lee wrote:
> I don't know the current state of Paul's rework of cpusets and
> mems_allowed. That probably resolves this issue, if he still plans on
> allowing a fully populated mask to indicate interleaving over all
> allowed nodes.
It got a bit stalled out for the last month (my employer had oth
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
s
On Tue, 05 Feb 2008 13:48:17 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD
> Opteron)
> box. This was seen in 2.6.24-rc8-mm1 either
> (http://lkml.org/lkml/2008/1/17/129).
>
> BUG: unable
Hi Andrew,
The 2.6.24-mm1 kernel panics while bootup on the x86_64 (Dual Core AMD Opteron)
box. This was seen in 2.6.24-rc8-mm1 either
(http://lkml.org/lkml/2008/1/17/129).
BUG: unable to handle kernel paging request at 4a78
IP: [] __alloc_pages+0x47/0x337
PGD 0
Oops: [1] SMP
* Sachin P. Sant <[EMAIL PROTECTED]> [2008-02-05 06:33]:
> Bernhard Walle wrote:
>> * Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
>>
>>> Bernahard, any idea who is the competitor here?
>>>
>> Hm ..., can you boot the kernel without crashkernel= and provide the
>> /proc/iomem?
>>
Sachin P. Sant wrote:
Bernhard Walle wrote:
* Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached is the /proc/iomem output with and without crash
Bernhard Walle wrote:
* Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Attached is the /proc/iomem output with and without crashkernel
parameter.
A
Hi!
>>> As the namespaces and the "containers" are being integrated in the
>>> kernel, these functionalities may be a first step to implement the
>>> checkpoint/restart of an application: in fact the existing API does not
>>> allow
>>> to specify or to change an ID when creating an IPC, when
* Vivek Goyal <[EMAIL PROTECTED]> [2008-02-04 19:38]:
>
> Bernahard, any idea who is the competitor here?
Hm ..., can you boot the kernel without crashkernel= and provide the
/proc/iomem?
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Sat, 2 Feb 2008, Andi Kleen wrote:
> To be honest I've never tried seriously to make 32bit NUMA policy
> (with highmem) work well; just kept it at a "should not break"
> level. That is because with highmem the kernel's choices at
> placing memory are seriously limited anyways so I doubt 32bit
On Mon, Feb 04, 2008 at 09:41:11PM +0530, Sachin P. Sant wrote:
> While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
> i ran into this problem. Here is the snippet from dmesg during the
> failure. [ dmesg log attached ]
>
> early_ioremap(000
On Sat, 2008-02-02 at 18:37 +0900, KOSAKI Motohiro wrote:
> Hi Andi,
>
> > > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> > >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> > >in mpol_check_policy()
> > >
> >
While trying to configure kdump with 2.6.24-rc8-mm1 [ on a x86-64 box ]
i ran into this problem. Here is the snippet from dmesg during the
failure. [ dmesg log attached ]
early_ioremap(040e, 0002) => -02103442418
early_iounmap(82a0040e, 0002)
early_iore
Pavel Machek wrote:
Hi!
* Patches 9 to 15 propose to add some functionalities, and thus are
submitted here for RFC, about both the interest and their implementation.
These functionalities are:
- Two new control-commands:
. IPC_SETID: to change an IPC's id.
. IPC_SETALL: beha
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> Kirill Korotaev wrote:
>>> Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
> Pierre,
>
> my point is that after you've added interface "set IPCID", you'll need
> more and more for checkpointing:
> - "
Pavel Emelyanov wrote:
Kirill Korotaev wrote:
Cedric Le Goater wrote:
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need
more and more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set t
Kirill Korotaev wrote:
>
> Cedric Le Goater wrote:
>> Hello Kirill !
>>
>> Kirill Korotaev wrote:
>>> Pierre,
>>>
>>> my point is that after you've added interface "set IPCID", you'll need
>>> more and more for checkpointing:
>>> - "create/setup conntrack" (otherwise connections get dropped),
>>>
Pavel Machek wrote:
> Hi!
>
>> * Patches 9 to 15 propose to add some functionalities, and thus are
>> submitted here for RFC, about both the interest and their implementation.
>> These functionalities are:
>> - Two new control-commands:
>> . IPC_SETID: to change an IPC's id.
>> . I
Cedric Le Goater wrote:
> Hello Kirill !
>
> Kirill Korotaev wrote:
>> Pierre,
>>
>> my point is that after you've added interface "set IPCID", you'll need
>> more and more for checkpointing:
>> - "create/setup conntrack" (otherwise connections get dropped),
>> - "set task start time" (needed fo
Hi!
> * Patches 9 to 15 propose to add some functionalities, and thus are
> submitted here for RFC, about both the interest and their implementation.
> These functionalities are:
> - Two new control-commands:
> . IPC_SETID: to change an IPC's id.
> . IPC_SETALL: behaves as IPC_SET,
> I have 1 simple question.
> Why do libnuma generate bitpattern of all bit on instead
> check /sys/devices/system/node/has_high_memory nor
> check /sys/devices/system/node/online?
>
> Do you know it?
It's far simpler and cheaper (sysfs is expensive) to do this in the kernel
and besides the ke
Hi Andi,
> > 3. 2.6.24-rc8-mm1 set_mempolicy(2) behavior
> >3.1 check nodesubset(nodemask argument, node_states[N_HIGH_MEMORY])
> >in mpol_check_policy()
> >
> > -> check failed when memmoryless node exist.
> >(i.e. node_sta
[intentional full quote]
On Sat, Feb 02, 2008 at 05:12:30PM +0900, KOSAKI Motohiro wrote:
> I tested numactl on 2.6.24-rc8-mm1.
> and I found strange behavior.
>
> test method and result.
>
> $ numactl --interleave=all ls
> set_mempolicy: Invalid argument
>
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
ftp://ftp.suse.com/pub/people/ak
On Tue, 22 Jan 2008 15:13:58 -0800
Dave Hansen <[EMAIL PROTECTED]> wrote:
> @@ -566,10 +567,26 @@ static void mark_files_ro(struct super_b
> {
> struct file *f;
>
> +retry:
> file_list_lock();
> list_for_each_entry(f, &sb->s_files, f_u.fu_list) {
> - if (S_ISREG(f-
* Sudhir Kumar <[EMAIL PROTECTED]> wrote:
> >http://redhat.com/~mingo/x86.git/README
> >
> > does that crash too?
>
> Sorry , unable to do that as the instrunctions at above location do
> not work. Something else I can try ?
hm, those instructions work fine here, if i do them anew. It end
Serge E. Hallyn wrote:
> Quoting Pierre Peiffer ([EMAIL PROTECTED]):
>>
>> Serge E. Hallyn wrote:
>>> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Pierre Peiffer <[EMAIL PROTECTED]>
In order to modify the semundo-list of a task from procfs, we must be able
to
wor
Quoting Pierre Peiffer ([EMAIL PROTECTED]):
>
>
> Serge E. Hallyn wrote:
> > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> >> From: Pierre Peiffer <[EMAIL PROTECTED]>
> >>
> >> In order to modify the semundo-list of a task from procfs, we must be able
> >> to
> >> work on any target task.
> >
Hello Kirill !
Kirill Korotaev wrote:
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some stati
On Mon, Jan 28, 2008 at 04:13:00PM +0100, Ingo Molnar wrote:
>
> * Sudhir Kumar <[EMAIL PROTECTED]> wrote:
>
> > I applied all the hot fixes patches but still the bug is there. (crash
> > at early boot).
> >
> > As I replied your earlier mail in which the patch sent by you does not
> > apply (
Pierre,
my point is that after you've added interface "set IPCID", you'll need more and
more for checkpointing:
- "create/setup conntrack" (otherwise connections get dropped),
- "set task start time" (needed for Oracle checkpointing BTW),
- "set some statistics counters (e.g. networking or taskst
Kirill Korotaev wrote:
> Why user space can need this API? for checkpointing only?
I would say "at least for checkpointing"... ;) May be someone else may find an
interest about this for something else.
In fact, I'm sure that you have some interest in checkpointing; and thus, you
have probably so
Pierre Peiffer wrote:
Nadia Derbey wrote:
[EMAIL PROTECTED] wrote:
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down() takes one unused parameter: semnum.
This patch proposes to get rid of it.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
-
Nadia Derbey wrote:
> [EMAIL PROTECTED] wrote:
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> semctl_down() takes one unused parameter: semnum.
>> This patch proposes to get rid of it.
>>
>> Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
>> Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
>> ---
Why user space can need this API? for checkpointing only?
Then I would not consider it for inclusion until it is clear how to implement
checkpointing.
As for me personally - I'm against exporting such APIs, since they are not
needed in real-life user space applications and maintaining it forever
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> Today, the sem_undo_list is freed when the last task using it exits.
>> There is no mechanism in place, that allows a safe concurrent access to
>> the sem_undo_list of a targe
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> From: Pierre Peiffer <[EMAIL PROTECTED]>
>>
>> In order to modify the semundo-list of a task from procfs, we must be able to
>> work on any target task.
>> But all the existing code playing with the semundo-list, currently
Hi again,
Thinking more about this, I think I must clarify why I choose this way.
In fact, the idea of these patches is to provide the missing user APIs (or
extend the existing ones) that allow to set or update _all_ properties of all
IPCs, as needed in the case of the checkpoint/restart o
[EMAIL PROTECTED] wrote:
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down() takes one unused parameter: semnum.
This patch proposes to get rid of it.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c |6 +++---
1 file changed, 3
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> From: Pierre Peiffer <[EMAIL PROTECTED]>
>
> Today, the sem_undo_list is freed when the last task using it exits.
> There is no mechanism in place, that allows a safe concurrent access to
> the sem_undo_list of a target task and protects efficiently
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> From: Pierre Peiffer <[EMAIL PROTECTED]>
>
> In order to modify the semundo-list of a task from procfs, we must be able to
> work on any target task.
> But all the existing code playing with the semundo-list, currently works
> only on the 'current'
Alexey Dobriyan wrote:
> On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote:
>> This patch provides three new API to change the ID of an existing
>> System V IPCs.
>>
>> These APIs are:
>> long msg_chid(struct ipc_namespace *ns, int id, int newid);
>> long sem_chid(struct
On Tue, Jan 29, 2008 at 05:02:38PM +0100, [EMAIL PROTECTED] wrote:
> This patch provides three new API to change the ID of an existing
> System V IPCs.
>
> These APIs are:
> long msg_chid(struct ipc_namespace *ns, int id, int newid);
> long sem_chid(struct ipc_namespace *ns, int id, in
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch adds the write operation to the semundo file.
This write operation allows root to add or update the semundo list and
their values for a given process.
The user must provide some lines, each containing the semaphores ID
followed by the semaphores
From: Pierre Peiffer <[EMAIL PROTECTED]>
In order to modify the semundo-list of a task from procfs, we must be able to
work on any target task.
But all the existing code playing with the semundo-list, currently works
only on the 'current' task, and does not allow to specify any target task.
This
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch adds a new procfs interface to display the per-process semundo
data.
A new per-PID file is added, named "semundo".
It contains one line per semaphore IPC where there is something to undo for
this process.
Then, each line contains the semid follo
From: Pierre Peiffer <[EMAIL PROTECTED]>
Today, the sem_undo_list is freed when the last task using it exits.
There is no mechanism in place, that allows a safe concurrent access to
the sem_undo_list of a target task and protects efficiently against a
task-exit.
That is okay for now as we don't n
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch adds a new IPC_SETALL command to the System V IPCs set of commands,
which allows to change all the settings of an IPC
It works exactly the same way as the IPC_SET command, except that it
additionally changes all the times and the pids values
Si
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch adds a new IPC_SETID command to the System V IPCs set of commands,
which allows to change the ID of an existing IPC.
This command can be used through the semctl/shmctl/msgctl API, with the new
ID passed as the third argument for msgctl and shmct
From: Pierre Peiffer <[EMAIL PROTECTED]>
This patch provides three new API to change the ID of an existing
System V IPCs.
These APIs are:
long msg_chid(struct ipc_namespace *ns, int id, int newid);
long sem_chid(struct ipc_namespace *ns, int id, int newid);
long shm_chid(s
semctl_down(), msgctl_down() and shmctl_down() are used to handle the same
set of commands for each kind of IPC. They all start to do the same job (they
retrieve the ipc and do some permission checks) before handling the commands
on their own.
This patch proposes to consolidate this by moving thes
From: Pierre Peiffer <[EMAIL PROTECTED]>
The IPC_SET command performs the same permission setting for all IPCs.
This patch introduces a common ipc_update_perm() function to update these
permissions and makes use of it for all IPCs.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge
From: Pierre Peiffer <[EMAIL PROTECTED]>
All IPCs make use of an intermetiate *_setbuf structure to handle the
IPC_SET command. This is not really needed and, moreover, it complicate
a little bit the code.
This patch get rid of the use of it and uses directly the semid64_ds/
msgid64_ds/shmid64_ds
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down is called with the rwmutex (the one which protects the
list of ipcs) taken in write mode.
This patch moves this rwmutex taken in write-mode inside semctl_down.
This has the advantages of reducing a little bit the window during
which this rwmutex
From: Pierre Peiffer <[EMAIL PROTECTED]>
semctl_down() takes one unused parameter: semnum.
This patch proposes to get rid of it.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(
From: Pierre Peiffer <[EMAIL PROTECTED]>
Currently, sys_msgctl is not easy to read.
This patch tries to improve that by introducing the msgctl_down function
to handle all commands requiring the rwmutex to be taken in write mode
(ie IPC_SET and IPC_RMID for now). It is the equivalent function of
se
From: Pierre Peiffer <[EMAIL PROTECTED]>
Currently, the way the different commands are handled in sys_shmctl
introduces some duplicated code.
This patch introduces the shmctl_down function to handle all the commands
requiring the rwmutex to be taken in write mode (ie IPC_SET and IPC_RMID
for now).
From: Pierre Peiffer <[EMAIL PROTECTED]>
Trivial patch which adds some small locking functions and makes use of them
to factorize some part of code and makes it cleaner.
Signed-off-by: Pierre Peiffer <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
---
ipc/sem.c | 61 +++
Hi,
Here is a patchset about the IPC, which proposes to consolidate some
part of the existing code and to add some functionalities.
* Patches 1 to 8 don't change the existing behavior, but propose to rewrite
some parts of the existing code. In fact, the three kinds of IPC (semaphores,
mes
Hello Takashi,
> > > > I was digging through the gentoo bugzilla and found this:
> > > >
> > > > http://bugs.gentoo.org/show_bug.cgi?id=141823
> > > >
> > > > As you see this bug is present since at least 2.6.17. I can reprodu
* Sudhir Kumar <[EMAIL PROTECTED]> wrote:
> I applied all the hot fixes patches but still the bug is there. (crash
> at early boot).
>
> As I replied your earlier mail in which the patch sent by you does not
> apply (reverse). can you please look into the problem ?
could you test latest x86.g
On Tue, Jan 22, 2008 at 04:53:30PM +0100, Ingo Molnar wrote:
>
Hi Ingo,
I applied all the hot fixes patches but still the bug is there.
(crash at early boot).
As I replied your earlier mail in which the patch sent by you
does not apply (reverse).
can you please look into the problem ?
Thanks
Sud
sent since at least 2.6.17. I can reproduce
> > > that here on my hardware with 2.6.24-rc8-mm1. All you need to do is
> > > install
> > > mp3blaster on sparc64, run:
> > >
> > > $ mp3blaster some_mp3_file.mp3
> > >
> > > and stop it by
he driver getting out of sync.
Signed-off-by: Arjan Opmeer <[EMAIL PROTECTED]>
---
diff -purN -X linux-2.6.24-rc8-mm1.vanilla/Documentation/dontdiff
linux-2.6.24-rc8-mm1.vanilla/Documentation/input/elantech.txt
linux-2.6.24-rc8-mm1.elantech/Documentation/input/elantech.txt
--- linux-2.6.24-
On Jan 17, 2008 11:35 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
I'm still seeing my mystery-crash that I had since 2.6.24-rc3-mm2.
The crashed kernel was 2.6.24-rc8-mm1 with the
Hello,
> > I was digging through the gentoo bugzilla and found this:
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=141823
> >
> > As you see this bug is present since at least 2.6.17. I can reproduce
> > that here on my hardware with 2.6.24-rc
t; that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
> mp3blaster on sparc64, run:
>
> $ mp3blaster some_mp3_file.mp3
>
> and stop it by pressing ctrl-c. It oopses when you stop it. It doesn't happen
> every time but it'll oops in a few tries.
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>>>>> NIP: 4570 LR: 0fc42dc0 CTR:
>>>>> REGS: c0077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
>>>>> MSR: 80001000 CR: 2802242
thermal soundcore rtc_cmos snd_page_alloc rtc_core rtc_lib
> > i2c_i801 processor button intel_agp dcdbas pcspkr agpgart
> > Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #8
> > [] ? have_callable_console+0x20/0x30
> > [] warn_on_slowpath+0x54/0x80
> > [] ? tcp_pr
Hello,
I was digging through the gentoo bugzilla and found this:
http://bugs.gentoo.org/show_bug.cgi?id=141823
As you see this bug is present since at least 2.6.17. I can reproduce
that here on my hardware with 2.6.24-rc8-mm1. All you need to do is install
mp3blaster on sparc64, run
-rc8-mm1 in this order :
markers-support-for-proprietary-modules.patch
#
#Instrumentation menu removal
fix-arm-to-play-nicely-with-generic-instrumentation-menu.patch
move-kconfig-instrumentation-to-arch.patch
#
#Text Edit Lock
kprobes-use-mutex-for-insn-pages.patch
kprobes-dont-use-kprobes-mutex-in
Dell Latitude D820 laptop, T7200 Core2 Duo, x86_64 kernel built with
PREEMPT, NO_HZ, and HZ=1000. It's running basically idle with an X desktop
session.
I'm seeing large masses of rescheduling interrupts that are basically killing
the C3 residency rate for no obvious reason/gain. I'm taking close
al soundcore rtc_cmos snd_page_alloc rtc_core rtc_lib
> > i2c_i801 processor button intel_agp dcdbas pcspkr agpgart
> > Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #8
> > [] ? have_callable_console+0x20/0x30
> > [] warn_on_slowpath+0x54/0x80
> > [] ? tcp_print_
ss eeprom e100 psmouse
> > snd_hda_intel snd_pcm snd_timer btusb bluetooth serio_raw snd 3c59x sg
> > evdev thermal soundcore rtc_cmos snd_page_alloc rtc_core rtc_lib
> > i2c_i801 processor button intel_agp dcdbas pcspkr agpgart
> > Pid: 0, comm: swapper Not tainted 2.6.
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
> And anyway, there were some fackets_out related
> problems reported as well and this doesn't help for that but I think I've
> lost track of who was seeing it due to large number of reports :-), could
> somebody refresh my memory because I currently do
100 psmouse
> snd_hda_intel snd_pcm snd_timer btusb bluetooth serio_raw snd 3c59x sg
> evdev thermal soundcore rtc_cmos snd_page_alloc rtc_core rtc_lib
> i2c_i801 processor button intel_agp dcdbas pcspkr agpgart
> Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #8
> []
Hi,
The following call trace is seen in the 2.6.24-rc8-mm1 kernel, which is same as
one of
the call trace you have given a debug patch at
http://marc.info/?l=linux-netdev&m=120107165228368&w=2
i was not able to apply the debug patch, can you kindly rebase the patch for
2.6.24-rc8-mm1 o
Hi Andrew,
The machine drops into xmon, while running the fsstress
on the cifs mounted partition.
1:mon> r
R00 = R16 =
R01 = c0017527f910 R17 =
R02 = d0862258 R18 =
R03 = 0001 R19 = 000
I 20 (level, low) -> IRQ 20
e100: eth1: e100_probe: addr 0xefaff000, irq 20, MAC addr 00:13:72:e7:4d:66
eth0: setting full-duplex.
[ cut here ]
WARNING: at net/ipv4/tcp_ipv4.c:197 tcp_verify_wq+0x1b6/0x1c0()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event
sn
1 - 100 of 229 matches
Mail list logo
