On Wednesday 27 February 2008 00:22, Otavio Salvador wrote:
> Hello,
>
> Today I got this oops, someone has an idea of what's going wrong?
>
> Unable to handle kernel paging request at 0200 RIP:
> [] find_get_pages+0x3c/0x69
At this point, the most likely candidate is a memory
On Tuesday 26 February 2008 18:21, Gleb Natapov wrote:
> On Tue, Feb 26, 2008 at 05:11:32PM +1100, Nick Piggin wrote:
> > > You are missing one point here. The MPI specifications that have
> > > been out there for decades do not require the process use a library
> >
On Tuesday 26 February 2008 18:59, Jamie Lokier wrote:
> Andrew Morton wrote:
> > On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier <[EMAIL PROTECTED]>
wrote:
> > > (It would be nicer if sync_file_range()
> > > took a vector of ranges for better elevator scheduling, but let's
> > > ignore that :-)
On Tuesday 26 February 2008 18:59, Jamie Lokier wrote:
Andrew Morton wrote:
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier [EMAIL PROTECTED]
wrote:
(It would be nicer if sync_file_range()
took a vector of ranges for better elevator scheduling, but let's
ignore that :-)
Two
On Tuesday 26 February 2008 18:21, Gleb Natapov wrote:
On Tue, Feb 26, 2008 at 05:11:32PM +1100, Nick Piggin wrote:
You are missing one point here. The MPI specifications that have
been out there for decades do not require the process use a library
for allocating the buffer. I realize
On Wednesday 27 February 2008 00:22, Otavio Salvador wrote:
Hello,
Today I got this oops, someone has an idea of what's going wrong?
Unable to handle kernel paging request at 0200 RIP:
[802735c3] find_get_pages+0x3c/0x69
At this point, the most likely candidate is a
On Thursday 21 February 2008 21:58, Robin Holt wrote:
> On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
> > > > So why can't you export a device from your xpmem driver, which
> > > > can be mmap()ed to give out "anonymous" memory pages to be
On Wednesday 20 February 2008 09:01, Alexey Dobriyan wrote:
> On Tue, Feb 19, 2008 at 11:47:11PM +0300, wrote:
> > > Are you reproducing it simply by running the
> > > ftest03 binary directly from the shell? How many times between oopses?
> > > It is multi-process but no threads, so races should
On Wednesday 20 February 2008 09:01, Alexey Dobriyan wrote:
On Tue, Feb 19, 2008 at 11:47:11PM +0300, wrote:
Are you reproducing it simply by running the
ftest03 binary directly from the shell? How many times between oopses?
It is multi-process but no threads, so races should be
On Thursday 21 February 2008 21:58, Robin Holt wrote:
On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
So why can't you export a device from your xpmem driver, which
can be mmap()ed to give out anonymous memory pages to be used
for these communication buffers
On Friday 22 February 2008 09:26, Peter Zijlstra wrote:
> On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote:
> > Some oprofile results obtained while using tbench on a 2x2 cpu machine
> > were very surprising.
> >
> > For example, loopback_xmit() function was using high number of cpu
> >
On Friday 22 February 2008 09:26, Peter Zijlstra wrote:
On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote:
Some oprofile results obtained while using tbench on a 2x2 cpu machine
were very surprising.
For example, loopback_xmit() function was using high number of cpu
cycles to
On Wednesday 20 February 2008 23:52, Balbir Singh wrote:
> Andi Kleen wrote:
> > Document huge memory/cache overhead of memory controller in Kconfig
> >
> > I was a little surprised that 2.6.25-rc* increased struct page for the
> > memory controller. At least on many x86-64 machines it will not
On Wednesday 20 February 2008 23:52, Balbir Singh wrote:
Andi Kleen wrote:
Document huge memory/cache overhead of memory controller in Kconfig
I was a little surprised that 2.6.25-rc* increased struct page for the
memory controller. At least on many x86-64 machines it will not fit into
On Wed, Feb 20, 2008 at 01:03:24PM +0100, Andrea Arcangeli wrote:
> If there's agreement that the VM should alter its locking from
> spinlock to mutex for its own good, then Christoph's
> one-config-option-fits-all becomes a lot more appealing (replacing RCU
> with a mutex in the mmu notifier list
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote:
> Given Nick's comments I ported my version of the mmu notifiers to
> latest mainline. There are no known bugs AFIK and it's obviously safe
> (nothing is allowed to schedule inside rcu_read_lock taken by
> mmu_notifier() with my
On Wed, Feb 20, 2008 at 02:09:41AM +0100, Andrea Arcangeli wrote:
> On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
> > Sorry, I realise I still didn't get this through my head yet (and also
> > have not seen your patch recently). So I don't know exactly what yo
On Tue, Feb 19, 2008 at 05:40:50PM -0600, Jack Steiner wrote:
> On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
> > On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
> > > On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
> > &g
On Wednesday 20 February 2008 20:00, Robin Holt wrote:
> On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
> > On Wednesday 20 February 2008 14:12, Robin Holt wrote:
> > > For XPMEM, we do not currently allow file backed
> > > mapping pages from being export
On Wednesday 20 February 2008 20:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach
On Tue, Feb 19, 2008 at 05:40:50PM -0600, Jack Steiner wrote:
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte
On Wed, Feb 20, 2008 at 02:09:41AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 12:11:57AM +0100, Nick Piggin wrote:
Sorry, I realise I still didn't get this through my head yet (and also
have not seen your patch recently). So I don't know exactly what you
are doing...
The last
On Wed, Feb 20, 2008 at 11:39:42AM +0100, Andrea Arcangeli wrote:
Given Nick's comments I ported my version of the mmu notifiers to
latest mainline. There are no known bugs AFIK and it's obviously safe
(nothing is allowed to schedule inside rcu_read_lock taken by
mmu_notifier() with my patch).
On Wed, Feb 20, 2008 at 01:03:24PM +0100, Andrea Arcangeli wrote:
If there's agreement that the VM should alter its locking from
spinlock to mutex for its own good, then Christoph's
one-config-option-fits-all becomes a lot more appealing (replacing RCU
with a mutex in the mmu notifier list
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
> For XPMEM, we do not currently allow file backed
> mapping pages from being exported so we should never reach this condition.
> It has been an issue since day 1. We have operated with that assumption
> for 6 years and have not had issues
On Wednesday 20 February 2008 14:00, Robin Holt wrote:
> On Wed, Feb 20, 2008 at 02:00:38AM +0100, Andrea Arcangeli wrote:
> > On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
> > > Also, how to you resolve the case where you are not allowed to sleep?
> > >
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
> These special additional callbacks are required because XPmem (and likely
> other mechanisms) do use their own rmap (multiple processes on a series
> of remote Linux instances may be accessing the memory of a process).
> F.e. XPmem may
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
> On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
> > anything when changing the pte to be _more_ permissive, and I don't
>
> Note that in my patch the invalidate_pages in mprotect can be
>
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
> The invalidation of address ranges in a mm_struct needs to be
> performed when pages are removed or permissions etc change.
>
> If invalidate_range_begin() is called with locks held then we
> pass a flag into invalidate_range() to
On Tue, Feb 19, 2008 at 08:27:25AM -0600, Jack Steiner wrote:
> > On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
> > > understand the need for invalidate_begin/invalidate_end pairs at all.
> >
> > The need of the pairs is crystal clear to me: range_begin is needed
> > for GRU
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
> On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
> > are rather similar. However I have tried to make a point of minimising the
> > impact the the core mm/. I don't see why we need to invalidate or fl
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
> > I think it was just a simple context switch benchmark, but not lmbench
> > (which I found to be a bit too variable). But it was a long time ago...
>
&
On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > I actually once measured context switching performance in the scheduler,
> > and removing the unlikely hint for testing RT tasks IIRC gave about 5%
> > per
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
> The invalidation of address ranges in a mm_struct needs to be
> performed when pages are removed or permissions etc change.
>
> If invalidate_range_begin() is called with locks held then we
> pass a flag into invalidate_range() to
On Sunday 17 February 2008 06:22, Christoph Lameter wrote:
> On Fri, 15 Feb 2008, Andrew Morton wrote:
> > > flush_cache_page(vma, address, pte_pfn(*pte));
> > > entry = ptep_clear_flush(vma, address, pte);
> > > + mmu_notifier(invalidate_page, mm, address);
> >
> > I
Index: linux-2.6/drivers/char/mmu_notifier_skel.c
===
--- /dev/null
+++ linux-2.6/drivers/char/mmu_notifier_skel.c
@@ -0,0 +1,255 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Well I started reviewing the mmu notifier code, but it is kind of hard to
know what you're talking about just by reading through code and not trying
your suggestions for yourself...
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
are rather similar. However I have
On Tuesday 19 February 2008 16:44, KOSAKI Motohiro wrote:
> background
>
> current VM implementation doesn't has limit of # of parallel reclaim.
> when heavy workload, it bring to 2 bad things
> - heavy lock contention
> - unnecessary swap out
>
>
On Tuesday 19 February 2008 16:44, KOSAKI Motohiro wrote:
background
current VM implementation doesn't has limit of # of parallel reclaim.
when heavy workload, it bring to 2 bad things
- heavy lock contention
- unnecessary swap out
abount 2
Index: linux-2.6/drivers/char/mmu_notifier_skel.c
===
--- /dev/null
+++ linux-2.6/drivers/char/mmu_notifier_skel.c
@@ -0,0 +1,255 @@
+#include linux/types.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
Well I started reviewing the mmu notifier code, but it is kind of hard to
know what you're talking about just by reading through code and not trying
your suggestions for yourself...
So I implemented mmu notifiers slightly differently. Andrea's mmu notifiers
are rather similar. However I have
On Sunday 17 February 2008 06:22, Christoph Lameter wrote:
On Fri, 15 Feb 2008, Andrew Morton wrote:
flush_cache_page(vma, address, pte_pfn(*pte));
entry = ptep_clear_flush(vma, address, pte);
+ mmu_notifier(invalidate_page, mm, address);
I just don't see
On Tuesday 19 February 2008 20:25, Andi Kleen wrote:
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
I actually once measured context switching performance in the scheduler,
and removing the unlikely hint for testing RT tasks IIRC gave about 5%
performance drop.
OT: what
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
I think it was just a simple context switch benchmark, but not lmbench
(which I found to be a bit too variable). But it was a long time ago...
Do you still have it?
I thought
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
are rather similar. However I have tried to make a point of minimising the
impact the the core mm/. I don't see why we need to invalidate or flush
I also tried
On Tue, Feb 19, 2008 at 08:27:25AM -0600, Jack Steiner wrote:
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
understand the need for invalidate_begin/invalidate_end pairs at all.
The need of the pairs is crystal clear to me: range_begin is needed
for GRU
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
The invalidation of address ranges in a mm_struct needs to be
performed when pages are removed or permissions etc change.
If invalidate_range_begin() is called with locks held then we
pass a flag into invalidate_range() to indicate
On Tue, Feb 19, 2008 at 02:58:51PM +0100, Andrea Arcangeli wrote:
On Tue, Feb 19, 2008 at 09:43:57AM +0100, Nick Piggin wrote:
anything when changing the pte to be _more_ permissive, and I don't
Note that in my patch the invalidate_pages in mprotect can be
trivially switched
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have
On Wednesday 20 February 2008 14:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:00:38AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 20, 2008 at 10:08:49AM +1100, Nick Piggin wrote:
Also, how to you resolve the case where you are not allowed to sleep?
I would have thought either you have
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this condition.
It has been an issue since day 1. We have operated with that assumption
for 6 years and have not had issues with
On Tuesday 19 February 2008 10:03, Dmitry Adamushko wrote:
> Hi,
>
>
> [ description ]
>
> Subject: kthread: add a memory barrier to kthread_stop()
>
> 'kthread' threads do a check in the following order:
> - set_current_state(TASK_INTERRUPTIBLE);
> - kthread_should_stop();
>
> and
On Tuesday 19 February 2008 16:58, Willy Tarreau wrote:
> On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > > Note in particular the last predictors; assuming branch ending
> > > with goto, including call, causing early function return or
> > &g
On Tuesday 19 February 2008 13:40, Arjan van de Ven wrote:
> On Tue, 19 Feb 2008 13:33:53 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Actually one thing I don't like about gcc is that I think it still
> > emits cmovs for likely/unlikely branches, which is si
On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
> On Tue, Feb 12, 2008 at 02:04:30PM -0800, Andrew Morton wrote:
> > > [ 4057.31] Pid: 7035, comm: ftest03 Not tainted
> > > 2.6.24-25f666300625d894ebe04bac2b4b3aadb907c861 #2 [ 4057.31] RIP:
> > > 0010:[] []
> > >
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > you have more faith in the authors knowledge of how his code actually
> > behaves than I think is warranted :)
>
> iirc there was a mm patch some time ago to keep track of the actual
> unlikely
On Mon, Feb 18, 2008 at 02:33:17PM +0100, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > and that scrapping the remote
> > softirq trigger stuff is sanest.
>
> I actually liked Nick's queued smp_function_call_single() patch. So even
> if it was not used for block I would still
On Mon, Feb 18, 2008 at 02:33:17PM +0100, Andi Kleen wrote:
Jens Axboe [EMAIL PROTECTED] writes:
and that scrapping the remote
softirq trigger stuff is sanest.
I actually liked Nick's queued smp_function_call_single() patch. So even
if it was not used for block I would still like to see
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
you have more faith in the authors knowledge of how his code actually
behaves than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual
unlikely values at
On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
On Tue, Feb 12, 2008 at 02:04:30PM -0800, Andrew Morton wrote:
[ 4057.31] Pid: 7035, comm: ftest03 Not tainted
2.6.24-25f666300625d894ebe04bac2b4b3aadb907c861 #2 [ 4057.31] RIP:
0010:[802596c8]
On Tuesday 19 February 2008 13:40, Arjan van de Ven wrote:
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Actually one thing I don't like about gcc is that I think it still
emits cmovs for likely/unlikely branches, which is silly (the gcc
developers seem
On Tuesday 19 February 2008 10:03, Dmitry Adamushko wrote:
Hi,
[ description ]
Subject: kthread: add a memory barrier to kthread_stop()
'kthread' threads do a check in the following order:
- set_current_state(TASK_INTERRUPTIBLE);
- kthread_should_stop();
and set_current_state() implies
On Tuesday 19 February 2008 16:58, Willy Tarreau wrote:
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
Note in particular the last predictors; assuming branch ending
with goto, including call, causing early function return or
returning negative constant are not taken. Just
On Saturday 16 February 2008 08:56, Török Edwin wrote:
> Hi Arjan,
>
> LatencyTOP says that sync_page is 'Writing a page to disk', however
> I see that even when no writes are involved, such as during a
> readdir, lseek, etc.
> Naming it a write is misleading, as no program is running that is
>
On Saturday 16 February 2008 14:37, Andrew Morton wrote:
> On Thu, 14 Feb 2008 22:49:02 -0800 Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> > Two callbacks to remove individual pages as done in rmap code
> >
> > invalidate_page()
> >
> > Called from the inner loop of rmap walks to invalidate
On Saturday 16 February 2008 14:37, Andrew Morton wrote:
On Thu, 14 Feb 2008 22:49:02 -0800 Christoph Lameter [EMAIL PROTECTED]
wrote:
Two callbacks to remove individual pages as done in rmap code
invalidate_page()
Called from the inner loop of rmap walks to invalidate pages.
On Saturday 16 February 2008 08:56, Török Edwin wrote:
Hi Arjan,
LatencyTOP says that sync_page is 'Writing a page to disk', however
I see that even when no writes are involved, such as during a
readdir, lseek, etc.
Naming it a write is misleading, as no program is running that is
doing
On Wednesday 13 February 2008 20:32, Andrew Morton wrote:
> On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <[EMAIL PROTECTED]>
wrote:
> > BTW is it really true that the buffer can never be locked by
> > anything else at this point?
>
> It has been for the past five o
On Wednesday 13 February 2008 20:01, Andrew Morton wrote:
> On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
> > :)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
> > :)&g
On Wednesday 13 February 2008 20:01, Andrew Morton wrote:
On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide [EMAIL PROTECTED] wrote:
On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
:)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
:) Almost certainly a hardware fail of some
On Wednesday 13 February 2008 20:32, Andrew Morton wrote:
On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin [EMAIL PROTECTED]
wrote:
BTW is it really true that the buffer can never be locked by
anything else at this point?
It has been for the past five or six years. With the page locked
On Wednesday 13 February 2008 17:06, Max Krasnyansky wrote:
> Nick Piggin wrote:
> > But don't let me dissuade you from making these good improvements
> > to Linux as well :) Just that it isn't really going to be hard-rt
> > in general.
>
> Actually that's the cool thi
On Tuesday 12 February 2008 04:27, Raúl Porcel wrote:
> Hi,
>
> We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm
> attaching the console log and the kernel config.
>
> Need to say that with a DEC Xp1000 it works fine, although they're
> different machines, of course.
> With
On Wednesday 13 February 2008 11:17, Nick Piggin wrote:
> On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
> > It's a trivial dumb module which does nothing but loads and unloads.
> > I redid ftest03 later without any suspicious activity and it oopsed the
> > same
On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote:
> David Miller wrote:
> > From: Nick Piggin <[EMAIL PROTECTED]>
> > Date: Tue, 12 Feb 2008 17:41:21 +1100
> >
> >> stop machine is used for more than just module loading and unloading.
>
On Wednesday 13 February 2008 00:10, Eugene Teo wrote:
> Sorry for the repeated emails. Kindly ignore the previous resend. Please
> review this instead. Thanks. I have tested this.
If it is causing this much problems, can you split the cleanups into
their own patches.
> [PATCH 2/2] mm: various
On Wednesday 13 February 2008 08:50, Alan Cox wrote:
> > Feb 12 19:55:08 butterfly kernel: hde: dma timeout error: status=0xd0 {
> > Busy } Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
>
> Your drive stopped responding.
>
> > Feb 12 19:55:08 butterfly kernel: hde: DMA disabled
On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
> On Tue, Feb 12, 2008 at 02:04:30PM -0800, Andrew Morton wrote:
> > On Sun, 10 Feb 2008 17:00:31 +0300
> >
> > Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > > This happened during LTP. FWIW, modprobe/rmmod trivial empty module
> > >
On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
On Tue, Feb 12, 2008 at 02:04:30PM -0800, Andrew Morton wrote:
On Sun, 10 Feb 2008 17:00:31 +0300
Alexey Dobriyan [EMAIL PROTECTED] wrote:
This happened during LTP. FWIW, modprobe/rmmod trivial empty module
together with cat
On Wednesday 13 February 2008 08:50, Alan Cox wrote:
Feb 12 19:55:08 butterfly kernel: hde: dma timeout error: status=0xd0 {
Busy } Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
Your drive stopped responding.
Feb 12 19:55:08 butterfly kernel: hde: DMA disabled
Feb 12
On Wednesday 13 February 2008 11:17, Nick Piggin wrote:
On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote:
It's a trivial dumb module which does nothing but loads and unloads.
I redid ftest03 later without any suspicious activity and it oopsed the
same way.
Ah crap. Hmm, maybe I
On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote:
David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 17:41:21 +1100
stop machine is used for more than just module loading and unloading.
I don't think you can just disable it.
Right, in particular
On Tuesday 12 February 2008 04:27, Raúl Porcel wrote:
Hi,
We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm
attaching the console log and the kernel config.
Need to say that with a DEC Xp1000 it works fine, although they're
different machines, of course.
With .22 it
On Wednesday 13 February 2008 00:10, Eugene Teo wrote:
Sorry for the repeated emails. Kindly ignore the previous resend. Please
review this instead. Thanks. I have tested this.
If it is causing this much problems, can you split the cleanups into
their own patches.
[PATCH 2/2] mm: various
On Wednesday 13 February 2008 17:06, Max Krasnyansky wrote:
Nick Piggin wrote:
But don't let me dissuade you from making these good improvements
to Linux as well :) Just that it isn't really going to be hard-rt
in general.
Actually that's the cool thing about CPU isolation. Get rid
On Tuesday 12 February 2008 15:10, Max Krasnyansky wrote:
> Rusty - Stop machine.
>After doing a bunch of testing last three days I actually downgraded
> stop machine changes from [highly experimental] to simply [experimental].
> Pleas see this thread for more info:
>
On Tuesday 12 February 2008 14:16, Robert Hancock wrote:
> Nick Piggin wrote:
> > On Tuesday 12 February 2008 10:17, Jonathan Corbet wrote:
> >> Avoid buffer overflows in get_user_pages()
> >>
> >> So I spent a while pounding my head against my monitor tr
On Tuesday 12 February 2008 10:17, Jonathan Corbet wrote:
> Avoid buffer overflows in get_user_pages()
>
> So I spent a while pounding my head against my monitor trying to figure
> out the vmsplice() vulnerability - how could a failure to check for
> *read* access turn into a root exploit? It
On Tuesday 12 February 2008 15:10, Max Krasnyansky wrote:
Rusty - Stop machine.
After doing a bunch of testing last three days I actually downgraded
stop machine changes from [highly experimental] to simply [experimental].
Pleas see this thread for more info:
On Tuesday 12 February 2008 14:16, Robert Hancock wrote:
Nick Piggin wrote:
On Tuesday 12 February 2008 10:17, Jonathan Corbet wrote:
Avoid buffer overflows in get_user_pages()
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how
On Tuesday 12 February 2008 10:17, Jonathan Corbet wrote:
Avoid buffer overflows in get_user_pages()
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns
On Monday 11 February 2008 11:35, Arjan van de Ven wrote:
> The http://www.kerneloops.org website collects kernel oops and
> warning reports from various mailing lists and bugzillas as well as
> with a client users can install to auto-submit oopses.
> Below is a top 10 list of the
On Monday 11 February 2008 11:35, Arjan van de Ven wrote:
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses/backtraces
On Fri, Feb 08, 2008 at 02:56:09PM -0800, Arjan van de Ven wrote:
> Nick Piggin wrote:
> >>>Maybe cpus these days have so much store bandwith that doing
> >>>things like the above is OK, but I doubt it :-)
> >>on modern x86 cpus the memset may even be fast
On Fri, Feb 08, 2008 at 07:09:07AM -0800, Arjan van de Ven wrote:
> David Miller wrote:
> >From: Linus Torvalds <[EMAIL PROTECTED]>
> >Date: Thu, 7 Feb 2008 09:42:56 -0800 (PST)
> >
> >>Can we please just stop doing these one-by-one assignments, and just do
> >>something like
> >>
> >>
On Fri, Feb 08, 2008 at 09:24:22AM +0100, Jens Axboe wrote:
> On Fri, Feb 08 2008, Nick Piggin wrote:
> > On Fri, Feb 08, 2008 at 08:59:55AM +0100, Jens Axboe wrote:
> > > On Fri, Feb 08 2008, Nick Piggin wrote:
> > > > And if you don't?
> > >
> > &
On Fri, Feb 08, 2008 at 08:59:55AM +0100, Jens Axboe wrote:
> On Fri, Feb 08 2008, Nick Piggin wrote:
> > And if you don't?
>
> Well if you don't ask for anything, you wont get anything :-)
> As I mentioned, the patch is a playing ground for trying various setups.
> Every
On Friday 08 February 2008 18:29, Eric Dumazet wrote:
> Nick Piggin a écrit :
> > On Friday 08 February 2008 13:13, Christoph Lameter wrote:
> >> are available in the git repository at:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git
On Fri, Feb 08, 2008 at 02:56:09PM -0800, Arjan van de Ven wrote:
Nick Piggin wrote:
Maybe cpus these days have so much store bandwith that doing
things like the above is OK, but I doubt it :-)
on modern x86 cpus the memset may even be faster if the memory isn't in
cache;
the explicit
1 - 100 of 3926 matches
Mail list logo
