"Chen, Kenneth W" <[EMAIL PROTECTED]> writes:
> Dmitriy Monakhov wrote on Monday, December 18, 2006 5:23 AM
>> This patch is result of discussion started week ago here:
>> http://lkml.org/lkml/2006/12/11/66
>> changes from original patch:
>> - Update wrong comments about i_mutex locking.
>> - Ad
On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
(...)
> Since it's apparent not everyone is aware of what we are doing, I'll
> mention briefly some of the bigger points.
>
> - We have contacted HP to see if we can get additional hardware, mind
> you though this is a long term solution and wi
Hi Aubery!
Aubrey wrote:
Hi Nick,
Thanks for your reply again, ;-).
On 12/19/06, Nick Piggin <[EMAIL PROTECTED]> wrote:
This should not happen because the pages are checked to ensure they are
from the same zone before merging.
How? page_is_buddy() only check if the buddy has the buddy fl
On Tue, 19 Dec 2006, Nick Piggin wrote:
>
> We never want to drop dirty data! (ignoring the truncate case, which is
> handled privately by truncate anyway)
Bzzt.
SURE we do.
We absolutely do want to drop dirty data in the writeout path.
How do you think dirty data ever _becomes_ clean data?
On Monday 18 December 2006 12:16, David Schwartz wrote:
> Combined responses to save bandwidth and reduce the number of times people
> have to press "d".
>
> > Agreed. You missed the point.
>
> I don't understand how you could lead with "agreed" and then proceed to
> completely ignore the entire po
On Mon, Dec 18, 2006 at 10:21:34PM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >I've uploaded the latest changes to the homepage.
>
> Thanks. But could you now update the patch so that it can be compiled
> with the current upstream kernel? At least has
> prob
Manish Regmi wrote:
Nick Piggin:
but
they look like they might be a (HZ quantised) delay coming from
block layer plugging.
Sorry i didn´t understand what you mean.
When you submit a request to an empty block device queue, it can
get "plugged" for a number of timer ticks before any IO is a
Hello David,
Tuesday, December 19, 2006, 2:59:11 AM, you wrote:
> On Monday 18 December 2006 4:54 pm, David Brownell wrote:
>> > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5&r2=1.6&f=h
>>
>> That patch you applied looks right to me -- why don't you
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
> Dave Jones wrote:
>
> > Eeek! page_mapcount(page) went negative! (-2)
>
> Hmm, probably happened once before, too.
You're right. Going back further in the log, I noticed
that it had happened again exactly at the time that cron r
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
> This patch (against 2.6.19/2.6.19.1) adds the four context switch
> values (voluntary context switches, involuntary context switches, and
> the same values accumulated from terminated child processes) to the
> end of /proc/*/stat, simil
On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > J.H. wrote:
> > ...
> > > >The root cause boils down to with git, gitweb and the normal mirroring
> > > >on the fron
Linus Torvalds wrote:
On Tue, 19 Dec 2006, Nick Piggin wrote:
We never want to drop dirty data! (ignoring the truncate case, which is
handled privately by truncate anyway)
Bzzt.
SURE we do.
We absolutely do want to drop dirty data in the writeout path.
How do you think dirty data ever _b
On Tue, 2006-12-19 at 07:34 +0100, Willy Tarreau wrote:
> On Sat, Dec 16, 2006 at 11:30:34AM -0800, J.H. wrote:
> (...)
> > Since it's apparent not everyone is aware of what we are doing, I'll
> > mention briefly some of the bigger points.
> >
> > - We have contacted HP to see if we can get additi
for the last couple of days, i've been unable to pull from linus'
2.6 repository. i consistently get:
$ git pull
fatal: unexpected EOF
Fetch failure:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
No changes.
even after several retries. i can clone it from scratch, i j
Dave Jones wrote:
On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
> Dave Jones wrote:
>
> > Eeek! page_mapcount(page) went negative! (-2)
>
> Hmm, probably happened once before, too.
You're right. Going back further in the log, I noticed
that it had happened again exactly at
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 18 Dec 2006 11:22:36 -0500, simo wrote:
> > With cifs, a directory search shows different sizes but opening
> > them by name gives identical contents:
> >
> > $ ll ipt_dscp* ipt_DSCP*
> > -r 1 me me 1581 Jan 28 2004 ipt_dscp.c
> > -r 1 me
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Dec 2006 12:06:20 +0800, Hawk Xu wrote:
> Our server(running Oracle 10g) is having a kernel panic problem:
<>
> Process swapper (pid: 0, threadinfo 80582000, task 80464300)
> Stack: 0296 8013f325 81007f7f54d0 000
On Mon, Dec 18, 2006 at 03:39:36PM +0100, Ingo Molnar wrote:
>
> * Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > If any of this proposals should be omitted or separated let me know.
>
> thanks for the fixes, they look good to me. I have reorganized the
> __lock_acquire() chan
On Tue, 2006-12-19 at 15:36 +1100, Nick Piggin wrote:
> plain text document attachment (fs-fix.patch)
> Index: linux-2.6/fs/buffer.c
> ===
> --- linux-2.6.orig/fs/buffer.c2006-12-19 15:15:46.0 +1100
> +++ linux-2.6/fs/
On Tue, 19 Dec 2006, Nick Piggin wrote:
>
> I wouldn't have thought it becomes clean by dropping it ;) Is this a
> trick question? My answer is that we clean a page by by taking some
> action such that the underlying data matches the data in RAM...
Sure.
> We don't "drop" any data until it has
Hi Tigran,
On Mon, 18 Dec 2006 10:04:39 + (GMT), Tigran Aivazian wrote:
> Ok, your patch is correct, although I assume you realize that it does
> nothing --- both the function and the data it operates on are inside
> CONFIG_HOTPLUG_CPU and checking include/linux/init.h I see that
> __cpuini
On Mon, 2006-12-18 at 11:18 -0800, Linus Torvalds wrote:
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index d8a842a..3f9061e 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page
> > goto unlock;
> >
> > entry = ptep_get_and
On Tue, 2006-12-19 at 07:46 +0100, Willy Tarreau wrote:
> On Sun, Dec 17, 2006 at 04:42:56PM -0800, J.H. wrote:
> > On Mon, 2006-12-18 at 00:37 +0200, Matti Aarnio wrote:
> > > On Sun, Dec 17, 2006 at 10:23:54AM -0800, Randy Dunlap wrote:
> > > > J.H. wrote:
> > > ...
> > > > >The root cause boils
On 12/19/06, Nick Piggin <[EMAIL PROTECTED]> wrote:
Hi Aubery!
That's right. I guess you can either align your zone sizes (must be
aligned to MAX_ORDER size), or add the zone check in page_is_buddy.
Adding the zone check in page_is_buddy fix the problem.
Thanks again, :)
-Aubrey
-
To unsubscr
Hi Linus,
This is just a bunch of minor patches and fixes for the drm tree.
The biggest change is to the intel driver to fix up some tearing issues,
and a small update to the radeon bounds check to fix r300 issue.
The rest are just cleanups and comment fixes..
Dave.
drivers/char/drm/drmP.h
Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed. So what? How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program. Both
>> forms ar
Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed. So what? How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program. Both
>> forms ar
o Misc smpboot/cpu hotplug path cleanups. I did those to supress the
warnings generated by MODPOST. These warnings are visible only
if CONFIG_RELOCATABLE=y.
o CONFIG_RELOCATABLE compiles the kernel with --emit-relocs option. This
option retains relocation information in vmlinux file and
o Some functions which should have been in init sections as they are called
only once. Put them in init sections. Otherwise MODPOST generates warning
as these functions are placed in .text and they end up accessing something
in init sections.
WARNING: vmlinux - Section mismatch: reference
o Entry startup_32 was in .text section but it was accessing some init
data too and it prompts MODPOST to generate compilation warnings.
WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params from
.text between '_text' (at offset 0xc0100029) and 'startup_32_smp'
WARNING: vmli
o init() is a non __init function in .text section but it calls many
functions which are in .init.text section. Hence MODPOST generates lots
of cross reference warnings on i386 if compiled with CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.text:smp_prepare_cpus
o Fix modpost generated warning.
WARNING: vmlinux - Section mismatch: reference to .init.text: from .text
between 'add_one_highpage_hotplug' (at offset 0xc0113d3f) and 'online_page'
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
arch/i386/mm/init.c |4 ++--
1 file changed, 2 insertion
This patch removes the unconverted ATM_TNETA1570 option that also lacks
any code in the kernel.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-rc1-mm1/drivers/atm/Kconfig.old2006-12-19
04:42:00.0 +0100
+++ linux-2.6.20-rc1-mm1/drivers/atm/Kconfig2006-12-19 0
This patch contains the following transformations from custom functions
to standard kernel version:
- fore200e_kmalloc() -> kzalloc()
- fore200e_kfree() -> kfree()
- fore200e_swap() -> cpu_to_be32()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/atm/fore200e.c | 166 ++
David Milburn wrote:
> User applications using the HDIO_DRIVE_TASK ioctl through libata
> expect specific ATA registers to be returned to userspace. Verified
> that ata_task_ioctl correctly returns register values to the
> smartctl application.
>
> Signed-off-by: David Milburn <[EMAIL PROTECTED]>
301 - 335 of 335 matches
Mail list logo
