I'm sorry with the lkml users for the unwanted noise. I did a mistake
with my mail client.
Francesco
2007/3/2, Francesco Pretto <[EMAIL PROTECTED]>:
I'll send you a message of the thread. You only have to answer it
(with reply-to function of your browser) changing the TO: address with
On Tue, 20 Feb 2007 12:35:49 +0100 Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
> The console subsystem already has an idea of a boot console, using the
> CON_BOOT flag. The implementation has some flaws though. The major
> problem is that presence of a boot console makes register_console()
>
2007/3/2, Dan Gilliam <[EMAIL PROTECTED]>:
Hi Francesco,
I just tried to submit a plea to that address, but it's not letting me
post to it (refused). Help!
Dan
I'll send you a message of the thread. You only have to answer it
(with reply-to function of your browser) changing the TO: address
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > Sure we will. And you believe that the the newer controllers will be able
> > to magically shrink the the SG lists somehow? We will offload the
> > coalescing of the page structs into bios in hardware or some such thing?
> > And the vmscans etc too?
>
> From: Paul E. McKenney <[EMAIL PROTECTED]>
>
> Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call
> as
> required.
>
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But most likely, 9f4bd5dd is actually already bad, and what you are
> seeing is two *different* bugs that just have the same symptoms
> ("suspend doesn't work").
the situation is simpler than that: there is a /known/ bug, and i marked
the bugfix
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a hardware ID of 0 (usually referred
> to as BSP on some architectures) does not hold true anymore. The reason
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Btw, you seem to have re-ordered the commits - the above is not the
> order you did the bisection in. The known-good commit (f3ccb06..) is
> in the middle. [...]
no - i simply picked them by hand, based on looking at gittk output,
because
On Thu, Mar 01, 2007 at 10:51:00PM -0800, Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Nick Piggin wrote:
>
> > > There was no talk about slightly. 1G page size would actually be quite
> > > convenient for some applications.
> >
> > But it is far from convenient for the kernel. So we have
> It's been pointed out that output GPIOs should have an initial value, to
> avoid signal glitching ... among other things, it can be some time
before
> a driver is ready. This patch corrects that oversight, fixing
>
> - documentation
> - platforms supporting the GPIO interface
> - users of
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote:
>
> That little change, buried in the middle of Alan's patch, changes the
> probing order for a /lot/ of devices, possibly millions, when you
> consider that it changes behavior of ata_piix (Intel SATA) as well as
> all the
On Friday 02 March 2007, Con Kolivas wrote:
>On 02/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> Greetings;
>>
>> I just rebooted to 2.6.21-rc2 and noted that getting x up and running
>> was about 15 seconds longer than usual. When it got a bash shell
>> going I went to it and ran htop which
On Thu, 22 Feb 2007 14:37:38 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> As the color offset is always within the first page of the slab,
> virt_to_page() works just fine without slabp->colouroff.
kernel BUG at mm/slab.c:1658!
invalid opcode: [#1]
SMP
last sysfs file:
Andrew Morton wrote:
> Perhaps Ulrich can comment.
I was out of town, hence the delay.
I think that if there is no support for the syscall the correct answer
is to return ENOSYS. In this case the current userlevel code would be
used and ENOSYS is also used to trigger the use of the compat code
On Friday 02 March 2007, Gene Heskett wrote:
>Greetings;
>
>I just rebooted to 2.6.21-rc2 and noted that getting x up and running
> was about 15 seconds longer than usual. When it got a bash shell going
> I went to it and ran htop which showed that the bulldog monitor was
> taking 90% of the cpu.
On Thu, Mar 01, 2007 at 05:54:01PM -0800, Kunal Trivedi wrote:
> 5) OOPS messages from console.
><1>Unable to handle kernel NULL pointer dereference at virtual
> address 0018
><1> printing eip:
><4>e01a40c9
><1>*pde =
><1>Oops: [#1]
><4>SMP
><4>Modules
On Thu, 1 Mar 2007 22:51:00 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> I'd love to have I/O support for huge pages.
direct-IO works.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 02/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
Greetings;
I just rebooted to 2.6.21-rc2 and noted that getting x up and running was
about 15 seconds longer than usual. When it got a bash shell going I
went to it and ran htop which showed that the bulldog monitor was taking
90% of the
Hi Andrew,
On Thu, 1 Mar 2007 16:11:06 -0800, Andrew Morton wrote:
> On Thu, 1 Mar 2007 13:55:16 +0100
> Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> > Most architectures' scatterlist.h use the type dma_addr_t, but omit
> > to include which defines it. This could lead to build
> > failures, so
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > There was no talk about slightly. 1G page size would actually be quite
> > convenient for some applications.
>
> But it is far from convenient for the kernel. So we have hugepages, so
> we can stay out of the hair of those applications and they can
Zachary Amsden wrote:
> Yeah, actually that does work, since you pass the km_type, we can use
> that. But I would rather not respin this for 2.6.21; getting this
> 100% right can be tricky, and we've already done a good deal of
> testing on this patch the way it is.
It seems fairly low risk to
On Thursday March 1, [EMAIL PROTECTED] wrote:
> On Fri, 2 Mar 2007 15:56:55 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
>
> > - conf->expand_progress = (sector_nr + i)*(conf->raid_disks-1);
> > + conf->expand_progress = (sector_nr + i) * new_data_disks);
>
> ahem.
It wasn't like that when I
On Fri, 2 Mar 2007 15:56:55 +1100 NeilBrown <[EMAIL PROTECTED]> wrote:
> - conf->expand_progress = (sector_nr + i)*(conf->raid_disks-1);
> + conf->expand_progress = (sector_nr + i) * new_data_disks);
ahem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
On Thu, Mar 01, 2007 at 10:19:48PM -0800, Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Nick Piggin wrote:
>
> > > >From the I/O controller and from the application.
> >
> > Why doesn't the application need to deal with TLB entries?
>
> Because it may only operate on a small section of the
Zachary Amsden wrote:
> That doesn't quite work, since we need to know which of the two -
> KM_PTE0 or KM_PTE1 is being mapped. But it could be moved to before
> the mapping, as you need, and take this as a parameter.
Err, kmap_atomic_pte gets passed the type - KM_PTE0 or KM_PTE1.
J
-
To
Jeremy Fitzhardinge wrote:
Jeremy Fitzhardinge wrote:
Hm, I don't think this interface will work for Xen. In Xen, whenever a
pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
called after the mapping has already been created, so its too late for Xen.
I was planning on
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > >From the I/O controller and from the application.
>
> Why doesn't the application need to deal with TLB entries?
Because it may only operate on a small section of the file and hopefully
splice the rest through? But yes support for mmapped I/O would
On Sat, 24 Feb 2007 12:22:11 + Ralf Baechle <[EMAIL PROTECTED]> wrote:
> sysdev.h uses THIS_MODULE so should include .
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> diff --git a/include/linux/sysdev.h b/include/linux/sysdev.h
> index 389ccf8..e699ab2 100644
> ---
On Fri, Mar 02, 2007 at 02:50:29PM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 1 Mar 2007 21:11:58 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > The whole DRAM power story is a bedtime story for gullible children. Don't
> > fall for it. It's not realistic. The hardware support for
On Thu, 01 Mar 2007 22:03:55 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Just curious .. What does posix_fallocate() return ?
bookmark this:
http://www.opengroup.org/onlinepubs/009695399/nfindex.html
Upon successful completion, posix_fallocate() shall return zero;
otherwise, an
On Thu, Mar 01, 2007 at 11:12:42PM +, Sean Young wrote:
> Apologies if this has already been reported.
>
> If I call clock_gettime(CLOCK_THREAD_CPUTIME_ID, .. ) twice I get:
>
> divide error: [#1]
> Modules linked in: binfmt_misc rfcomm l2cap bluetooth sonypi speedstep_ich
>
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
hi David,
> It's been pointed out that output GPIOs should have an initial value, to
> avoid signal glitching ... among other things, it can be some time before
> a driver is ready. This patch corrects that oversight, fixing
For the AT91 changes:
Acked-by: Andrew Victor <[EMAIL PROTECTED]>
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > You do not have to deal with TLB entries if you do buffered I/O.
>
> Where does the data come from?
>From the I/O controller and from the application.
> > We currently have problems with the kernel limits of 128 SG
> > entries but the fundamental
On Thu, 1 Mar 2007 21:11:58 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> The whole DRAM power story is a bedtime story for gullible children. Don't
> fall for it. It's not realistic. The hardware support for it DOES NOT
> EXIST today, and probably won't for several years. And the
On Fri, 2 Mar 2007, Nick Piggin wrote:
> So what do you mean by efficient? I guess you aren't talking about CPU
> efficiency, because even if you make the IO subsystem submit larger
> physical IOs, you still have to deal with 256 billion TLB entries, the
> pagecache has to deal with 256 billion
On Thu, Mar 01, 2007 at 09:40:45PM -0800, Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Nick Piggin wrote:
>
> > So what do you mean by efficient? I guess you aren't talking about CPU
> > efficiency, because even if you make the IO subsystem submit larger
> > physical IOs, you still have to deal
Greetings;
I just rebooted to 2.6.21-rc2 and noted that getting x up and running was
about 15 seconds longer than usual. When it got a bash shell going I
went to it and ran htop which showed that the bulldog monitor was taking
90% of the cpu. Killed it, then restarted it, but when I ran the
On Fri, 2 Mar 2007, Nick Piggin wrote:
> So what do you mean by efficient? I guess you aren't talking about CPU
> efficiency, because even if you make the IO subsystem submit larger
> physical IOs, you still have to deal with 256 billion TLB entries, the
> pagecache has to deal with 256 billion
During initialization, mv643xx driver registers IRQ before setting up tx/rx
rings. This causes kernel oops because mv643xx_poll, which gets called
right after registering IRQ, calls netif_rx_complete, which accesses the rx
ring (I don't have the oops message anymore; I just remember this sequence
Srivatsa Vaddagiri wrote:
Heavily based on Paul Menage's (inturn cpuset) work. The big difference
is that the patch uses task->nsproxy to group tasks for resource control
purpose (instead of task->containers).
The patch retains the same user interface as Paul Menage's patches. In
particular,
Andrew,
On Thu, Mar 01, 2007 at 04:47:42PM -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 15:32:22 +0100
> "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
>
> > Hi folks,
> > this patch fixes the floppy mount bug (i. e. regression) in kernel
> > 2.6.21-rc1. It was inspired by Stephane Eranian. It was
On Thu, Mar 01, 2007 at 09:09:42PM -0800, Andrew Morton wrote:
> > or document that drivers need to handle it specially and give them a
> > way to find out about them. (Or do the horrible slab refcounting hack
> > I wrote up above)
>
> OK. So you're proposing that XFS and ext3 simply stop sing
Linus Torvalds wrote:
> Virtualization in general. We don't know what it is - in IBM machines it's
> a hypervisor. With Xen and VMware, it's usually a hypervisor too. With
> KVM, it's obviously a host Linux kernel/user-process combination.
>
> The point being that in the guests, hotunplug is
On Thu, 1 Mar 2007, Andrew Morton wrote:
>
> On Thu, 1 Mar 2007 19:44:27 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
>
> > In other words, I really don't see a huge upside. I see *lots* of
> > downsides, but upsides? Not so much. Almost everybody who wants unplug
> > wants
On Fri, 2 Mar 2007 05:03:51 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 01, 2007 at 09:00:44PM -0800, Andrew Morton wrote:
> > I that case we're talking about different things.
> >
> > I thought the proposal was to continue to use slab pages, but to take a ref
> > on them as
On Thu, Mar 01, 2007 at 08:31:24PM -0800, Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Nick Piggin wrote:
>
> > > Yes, we (SGI) need exactly that: Use of higher order pages in the kernel
> > > in order to reduce overhead of managing page structs for large I/O and
> > > large memory
On Thu, Mar 01, 2007 at 09:00:44PM -0800, Andrew Morton wrote:
> I that case we're talking about different things.
>
> I thought the proposal was to continue to use slab pages, but to take a ref
> on them as they're added to the bio, drop that ref in bi_end_io()?
That would give you silent
On Fri, 2 Mar 2007 04:49:10 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 01, 2007 at 08:48:06PM -0800, Andrew Morton wrote:
> > On Fri, 2 Mar 2007 04:30:39 + Christoph Hellwig <[EMAIL PROTECTED]>
> > wrote:
> >
> > > But in this case we'd really need to enforce this, and
On Thu, 1 Mar 2007 20:33:04 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 1 Mar 2007, Andrew Morton wrote:
>
> > Sorry, but this is crap. zones and nodes are distinct, physical concepts
> > and you're kidding yourself if you think you can somehow fudge things to
> > make
### Comments for Changeset
Recent patch for raid6 reshape had a change missing that showed up in
subsequent review.
Many places in the raid5 code used "conf->raid_disks-1" to mean
"number of data disks". With raid6 that had to be changed to
"conf->raid_disk - conf->max_degraded" or similar.
This patch adds the documentation for
/proc//coredump_omit_anonymous_shared.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt | 38 +++
1 files changed, 38 insertions(+)
Index: linux-2.6.20-mm2/Documentation/filesystems/proc.txt
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
This patch enables to omit anonymous shared memory from an ELF
formatted core file when it is generated.
Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
Index: linux-2.6.20-mm2/fs/binfmt_elf.c
On Thu, Mar 01, 2007 at 08:48:06PM -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 04:30:39 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > But in this case we'd really need to enforce this, and add a
> > BUG_ON(PageSlab(page)) in bio_add_page to trip everyone submit
> > this kind of
This patch adds an interface to set/reset a flag which determines
anonymous shared memory segments should be dumped or not when a core
file is generated.
/proc//coredump_omit_anonymous_shared file is provided to access
the flag. You can change the flag status for a particular process by
writing
On Fri, 2 Mar 2007 04:30:39 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> But in this case we'd really need to enforce this, and add a
> BUG_ON(PageSlab(page)) in bio_add_page to trip everyone submit
> this kind of pages.
That would be
BUG_ON(PageSlab(page) && page_count(page) ==
On Thursday, 1-Mar-2007 at 7:22 PST, Andrew Morton wrote:
> On Thu, 01 Mar 2007 03:47:39 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
> > Rusty Russell wrote:
> > > On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
> > >
> > >> What would be really, really nice would be to
Hi,
This patch series is version 4 of the core dump masking feature,
which provides a per-process flag not to dump anonymous shared
memory segments.
In the previous version, the flag value was passed around the core
dump functions as an argument to use the same setting while dumping.
In this
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > Yes, we (SGI) need exactly that: Use of higher order pages in the kernel
> > in order to reduce overhead of managing page structs for large I/O and
> > large memory applications. We need appropriate measures to deal with the
> > fragmentation problem.
On Thu, 1 Mar 2007, Andrew Morton wrote:
> Sorry, but this is crap. zones and nodes are distinct, physical concepts
> and you're kidding yourself if you think you can somehow fudge things to make
> one of them just go away.
>
> Think: ZONE_DMA32 on an Opteron machine. I don't think there is a
They don't really save that much, and aren't worth the hassle.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |2 --
./net/sunrpc/svcsock.c | 13 +++--
2 files changed, 3 insertions(+), 12 deletions(-)
diff
On Thu, Mar 01, 2007 at 07:22:45PM -0800, Andrew Morton wrote:
> Well I spose slab _could_ take a ref on these pages.
What it would need to do is:
- add a reference for every object touching this page
- don't give the page back to the page allocator or reuse any
single object inside it
When recv_msg is called with a size of 0 and MSG_PEEK (and
sunrpc/svcsock.c does), it is clear that we only interested in
metadata (from/to addresses) and not the data, so don't do any
checksum checking at this point. Leave that until the data is
requested.
Signed-off-by: Neil Brown <[EMAIL
On Thu, 1 Mar 2007 20:06:25 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> No merge them to one thing and handle them as one. No difference between
> zones and nodes anymore.
Sorry, but this is crap. zones and nodes are distinct, physical concepts
and you're kidding yourself if
The sunrpc server code needs to know the source and destination address
for UDP packets so it can reply properly.
It currently copies code out of the network stack to pick the pieces out
of the skb.
This is ugly and causes compile problems with the IPv6 stuff.
So, rip that out and use recv_msg
Current mainline has a compile linkage problem if both
CONFIG_IPV6=m
CONFIG_SUNRPC=y
because net/sunrpc/svcsock.c conditionally used a function defined in the IPv6
module.
These three patches resolve the issue.
The problem is caused because svcsock needs to get the source and
destination
On Fri, Mar 02, 2007 at 04:57:51AM +0100, Nick Piggin wrote:
> On Thu, Mar 01, 2007 at 07:05:48PM -0800, Christoph Lameter wrote:
> > On Thu, 1 Mar 2007, Andrew Morton wrote:
> > > For prioritisation purposes I'd judge that memory hot-unplug is of similar
> > > value to the antifrag work (because
Avi Kivity wrote:
Sid Boyce wrote:
> That's very much appreciated. The point is that all vanilla
kernels up
> to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and
> 2.6.20-rc2 and like other problems reported, sic framebuffer, etc.,
> there is a distinct likelihood that it's related
On Thu, Mar 01, 2007 at 08:06:25PM -0800, Christoph Lameter wrote:
> On Fri, 2 Mar 2007, Nick Piggin wrote:
>
> > > I would say that anti-frag / defrag enables memory unplug.
> >
> > Well that really depends. If you want to have any sort of guaranteed
> > amount of unplugging or shrinking (or
Jeremy Fitzhardinge wrote:
> Hm, I don't think this interface will work for Xen. In Xen, whenever a
> pagetable page gets mapped, it must be mapped RO. map_pt_hook gets
> called after the mapping has already been created, so its too late for Xen.
>
> I was planning on adding kmap_atomic_pte()
Linus Torvalds wrote:
On Fri, 2 Mar 2007, Balbir Singh wrote:
My personal opinion is that while I'm not a huge fan of virtualization,
these kinds of things really _can_ be handled more cleanly at that layer,
and not in the kernel at all. Afaik, it's what IBM already does, and has
been doing
On Thu, Mar 01, 2007 at 09:06:48AM -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > systems (see "linux/smp.h") is not correct.
> >
> > This patch-set does the
On Fri, 2 Mar 2007, Nick Piggin wrote:
> > I would say that anti-frag / defrag enables memory unplug.
>
> Well that really depends. If you want to have any sort of guaranteed
> amount of unplugging or shrinking (or hugepage allocating), then antifrag
> doesn't work because it is a heuristic.
We
On Thu, 1 Mar 2007 19:44:27 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> In other words, I really don't see a huge upside. I see *lots* of
> downsides, but upsides? Not so much. Almost everybody who wants unplug
> wants virtualization, and right now none of the "big virtualization"
On Thu, Mar 01, 2007 at 07:05:48PM -0800, Christoph Lameter wrote:
> On Thu, 1 Mar 2007, Andrew Morton wrote:
> > For prioritisation purposes I'd judge that memory hot-unplug is of similar
> > value to the antifrag work (because memory hot-unplug permits DIMM
> > poweroff).
>
> I would say that
On Thu, Mar 01, 2007 at 08:52:07PM +0300, Oleg Nesterov wrote:
> > --- a/arch/i386/kernel/sysenter.c~fully-honor-vdso_enabled
> > +++ a/arch/i386/kernel/sysenter.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > /*
> > * Should the kernel
On Fri, 2 Mar 2007, Balbir Singh wrote:
>
> > My personal opinion is that while I'm not a huge fan of virtualization,
> > these kinds of things really _can_ be handled more cleanly at that layer,
> > and not in the kernel at all. Afaik, it's what IBM already does, and has
> > been doing for a
On Thu, 1 Mar 2007 16:09:15 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 1 Mar 2007 10:12:50 +
> [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > Any opinion on merging these patches into -mm
> > for wider testing?
>
> I'm a little reluctant to make changes to -mm's core mm unless
On Fri, 2 Mar 2007 02:29:19 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 01, 2007 at 05:42:04PM -0800, Andrew Morton wrote:
> > Something funny is going on here.
>
> Not so funny for those who've tried to sort out the issue over
> the past years and just got ignored..
>
> >
On Thu, Mar 01, 2007 at 11:29:03AM -0800, Josh Triplett wrote:
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Josh Triplett <[EMAIL PROTECTED]>
> ---
> The corresponding rcu_torture_cleanup cannot get marked as __exit, because
> rcu_torture_init uses it to clean up if init fails.
On Thu, 2007-03-01 at 09:06 -0500, Benjamin LaHaise wrote:
> On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> > As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> > systems (see "linux/smp.h") is not correct.
> >
> > This patch-set does the
Zachary Amsden wrote:
> Provide a PT map hook for HIGHPTE kernels to designate where they are mapping
> page tables. This information is required so the physical address of PTE
> updates can be determined; otherwise, the mm layer would have to carry the
> physical address all the way to each PTE
On Thu, 1 Mar 2007, Andrew Morton wrote:
> What worries me is memory hot-unplug and per-container RSS limits. We
> don't know how we're going to do either of these yet, and it could well be
> that the anti-frag work significantly complexicates whatever we end up
> doing there.
Right now it
On Wed, Feb 28, 2007 at 09:52:34PM -0800, Andrew Morton wrote:
> On Mon, 26 Feb 2007 00:45:00 -0600 [EMAIL PROTECTED] (Florin Iucha) wrote:
>
> > Hello, it's me and my 70 GB of photos again.
[snip]
> > Running 'top', one core is idle and the other is 99% waiting, while
> > the 'cp' program is in
More goo from hrtimers integration. We do compile and run properly with NO_HZ
enabled. There was a period when we didn't because of a missing export, but
that was since fixed.
And with the clocksource code now firmly in place, we can get rid of code
that fixes up the wallclock, since this is
The time_init_hook in paravirt-ops no longer functions in the correct manner
after the integration of the hrtimers code. The problem is that now the
call path for time initialization is:
time_init :
late_time_init = hpet_time_init;
late_time_init -> hpet_time_init:
Critical fixes for SMP.
Fix a couple functions which needed to be __devinit and fix a bogus
parameter to AP startup that just so happened to work because the
low virtual mapping of memory was still established.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r baf2e278a482
Use para_fill instead of directly setting the APIC ops to the result of the
vmi_get_function call - this allows one to implement a VMI ROM without
implementing APIC functions, just using the native APIC functions.
While doing this, I realized that there is a lot more cleanup that should
have been
Not respecting udelay causes problems with any virtual hardware that is
passed through to real hardware. This can be noticed by any device that
interacts with the real world in real time - like AP startup, which takes
real time. Or keyboard LEDs, which should blink in real-time. Or floppy
Provide a PT map hook for HIGHPTE kernels to designate where they are mapping
page tables. This information is required so the physical address of PTE
updates can be determined; otherwise, the mm layer would have to carry the
physical address all the way to each PTE modification callsite, which
On Thu, 01 Mar 2007 18:17:56 -0800 [EMAIL PROTECTED] wrote:
> Today's print_symbol function dumps a kernel symbol with printk. This
> patch extends the functionality of kallsyms.c so that the symbol lookup
> function may be used without the printk. This is useful for modules that
> want to dump
In order to share the common code in tsc.c which does CPU Khz calibration, we
need to make an accurate value of CPU speed available to the tsc.c code.
This value loses a lot of precision in a VM because of the timing differences
with real hardware, but we need it to be as precise as possible so
Critical bugfixes for the VMI-Timer code.
1) Do not setup a one shot alarm if we are keeping the periodic alarm
armed. Additionally, since the periodic alarm can be run at a lower
rate than HZ, let's fixup the guard to the no-idle-hz mode appropriately.
This fixes the bug where the no-idle-hz
The custom_sched_clock hook is broken. The result from sched_clock needs to be
in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose,
because TSC is poorly defined in a virtual environment, and mostly represents
real world time instead of scheduled process time (which can
Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code.
Please apply. If there are objections to certain pieces, they can be
reworked, but they are pretty much all needed for correctness. We are
hoping to get these in the next 2.6.21-rc release.
We had quite a few
It would appear the new clockevent API has a one-nanosecond resolution.
It certainly looks sufficiently fine-grained, but I'm afraid it's too
coarse for some applications.
In our application, we need periodic clock interrupts at about 100 kHz.
If the (programmable) frequency must be rounded to
On Wed, 28 Feb 2007 08:32:43 -0800
Alex Romosan <[EMAIL PROTECTED]> wrote:
> the backlight on my thinkpad still (2.6.20 worked fine) doesn't come
> on if i have the radeon backlight enabled. without it, i guess it's
> the ibm acpi modules that controls the backlight and it seems to work
> fine.
>
Driver to throttle IO to reduce risk of OS timing out cmds.
Implemented a circular queue to keep track of pending OS cmds in FW.
This queue is periodically (every 10 sec) checked by a timer routine.
If there is any cmd that is in risk of getting timed-out by the OS,
the host->can_queue is
1 - 100 of 1065 matches
Mail list logo
