On 23/03/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >> > BUG: at kernel/fork.c:1033 copy_process()
> >>
> >> thanks Michal - this is a real bug that affects upstream too. Find
> >> the fix below - i've test-booted it and it fixes the warning.
> >
On Fri, 23 Mar 2007 14:04:30 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> This is the latest blackfin update patch.
I think I'm going to give up on the present set of blackfin patches. I don't
know whether what I have is up-to-date and various versions of various random
patches keep on flying
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >> Hibernation is still broken.
> >>
> >>
> >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/console.log
> >>
> >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/rt-config
> >
> >what's the failure m
On Thu, 2007-03-22 at 23:59 -0800, Andrew Morton wrote:
> On Fri, 23 Mar 2007 14:04:30 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
>
> > This is the latest blackfin update patch.
>
> I think I'm going to give up on the present set of blackfin patches. I don't
> know whether what I have is up-to
On 23/03/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> >> Hibernation is still broken.
> >>
> >>
>
>http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4-rt0/console.log
> >>
>
>http://www.stardust.webpages.pl/files/tbf/bitis-gabonic
Vivek Goyal napisał(a):
> On Thu, Mar 22, 2007 at 02:27:25PM +0100, Michal Piotrowski wrote:
>> Michal Piotrowski napisał(a):
>>> On 22/03/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
> 2.6.21-rc4-rt0
> BUG: at kernel/for
Hi Li,
> > Is the tool you mentioned last June [1] available for splitting up the
> > old firmware files to the new format (eg
> > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > Intel (or otherwise) in this new format?
> Yes, we are preparing the new format data files and m
On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked about a character device that would
behave like /dev/zero. Many of the peo
Con Kolivas wrote:
> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels
>> so I have just fired
Latest version of RSDL cpu scheduler (v0.33) for various trees available here:
http://ck.kolivas.org/patches/staircase-deadline/
--
-ck
-
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.kern
Implement queued spinlocks for i386. This shouldn't increase the size of
the spinlock structure, while still able to handle 2^16 CPUs.
Not completely implemented with assembly yet, to make the algorithm a bit
clearer.
The queued spinlock has 2 fields, a head and a tail, which are indexes
into a
wondering that here are 13 postings about loopdevice limitation, but
nobody giving any comment about dm-loop (
http://sources.redhat.com/lvm2/wiki/DMLoop ), which is a solution for
this problem ..
If I understand it correctly, I would need 'dm' in kernel (or module)
and moreover I would nee
On Fri, 2007-03-23 at 10:43 +0100, Marcel Holtmann wrote:
> Hi Li,
>
> > > Is the tool you mentioned last June [1] available for splitting up the
> > > old firmware files to the new format (eg
> > > /lib/firmware/intel-ucode/06-0d-06), or are updates available from
> > > Intel (or otherwise) in th
Marcus Better wrote:
> The XFS workqueue patch [1] fixes my problem [2].
> [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> [2] http://permalink.gmane.org/gmane.linux.kernel/505570
Unfortunately it only fixed suspend to RAM. Suspend to disk still hangs
at "snapshotting system". Will try
On Mon, 5 Mar 2007, Amedee Van Gasse wrote:
> It _appears_ that the bug reports started after an update of
> bluez-utils, but this remains to be confirmed. It could be
> coincidence/temporal correlation (which does not imply causation).
Hi Amedee,
did you have time to confirm whether this star
oops, sorry for the extra posts :(
Changelog?
Latest version of RSDL cpu scheduler (v0.33) for various trees available here:
http://ck.kolivas.org/patches/staircase-deadline/
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
ok, just ignore my post, best to look at the patch first
On 3/23/07, mdew . <[EMAIL PROTECTED]> wrote:
oops, sorry for the extra posts :(
> Changelog?
>
> Latest version of RSDL cpu scheduler (v0.33) for various trees available here:
>
> http://ck.kolivas.org/patches/staircase-deadline/
>
> --
On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
> On 23/03/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>
> >> and that in turn points to the kernel log:
> >>
> >>
> >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
> >
> >Seems convinci
On Fri, 23 Mar 2007 09:59:11 +0100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Implement queued spinlocks for i386. This shouldn't increase the size of
> the spinlock structure, while still able to handle 2^16 CPUs.
>
> Not completely implemented with assembly yet, to make the algorithm a bit
> c
On Fri, Mar 23, 2007 at 10:40:17AM +0100, Eric Dumazet wrote:
> On Fri, 23 Mar 2007 09:59:11 +0100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> >
> > Implement queued spinlocks for i386. This shouldn't increase the size of
> > the spinlock structure, while still able to handle 2^16 CPUs.
> >
> >
Hi all,
I just installed Red Hat Enterprise Linux AS release 4 (Nahant Update
4) on a Dell PE1950 server, which has two of dual-core Xeon 5110
1.6GHz CPUs. According to the processor spec @
http://processorfinder.intel.com/details.aspx?sSpec=SL9RZ , it doesn't
support Hyper-threading technology,
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Implement queued spinlocks for i386. [...]
isnt this patented by MS? (which might not worry you SuSE/Novell guys,
but it might be a worry for the rest of the world ;-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Fri, Mar 23, 2007 at 10:14:11 +0100, Marcus Better wrote:
> Marcus Better wrote:
> > The XFS workqueue patch [1] fixes my problem [2].
>
> > [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> > [2] http://permalink.gmane.org/gmane.linux.kernel/505570
>
> Unfortunately it only fixed sus
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Thu, 22 Mar 2007 07:23:06 -0500,
> >
> > This would indicate that dev_uevent had been called. But how could
> > kobject_uevent then return an error without moaning about an uevent()
> > error
On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Implement queued spinlocks for i386. [...]
>
> isnt this patented by MS? (which might not worry you SuSE/Novell guys,
> but it might be a worry for the rest of the world ;-)
I never
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
for-linus
to receive the appended fix for 2.6.21-rc4. Or apply from this mail.
Thanks.
(The eth1394 issue will be revised as soon as ieee1394 core got rid of
class_Device
On Thu, Mar 22, 2007 at 05:51:11PM -0700, Ken Chen wrote:
> It is really sad that we always call kmap and friends for every pipe
> buffer page on 64-bit arch that doesn't use HIGHMEM, or on
> configuration that doesn't turn on HIGHMEM.
>
> The effect of calling kmap* is visible in the execution pr
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Dave Hansen <[EMAIL PROTECTED]> writes:
>>
>>
>>>So, I think we have a difference of opinion. I think it's _all_ about
>>>memory pressure, and you think it is _not_ about accounting for memory
>>>pressure. :) Perhaps we mean d
On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Implement queued spinlocks for i386. [...]
>
> isnt this patented by MS? (which might not worry you SuSE/Novell guys,
> but it might be a worry for the rest of the world ;-)
Hmm, it
Michael Ellerman <[EMAIL PROTECTED]> writes:
> On Thu, 2007-03-22 at 15:08 -0700, Greg KH wrote:
>> On Fri, Mar 23, 2007 at 09:02:16AM +1100, Benjamin Herrenschmidt wrote:
>> > > > i.e. First the simple bug fixes that should purely be restructure of
>> > > > msi.c with no affect on anything outsi
On Fri, 23 Mar 2007 11:32:44 +0100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
> >
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Implement queued spinlocks for i386. [...]
> >
> > isnt this patented by MS? (which might not worry
tps://www.x86-64.org/pipermail/discuss/2005-March/005902.html
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Finalmente il design sposa il riscaldamento
vieni a scoprire i prodotti
Tubor
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6164&d=
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
Dave Hansen <[EMAIL PROTECTED]> writes:
So, I think we have a difference of opinion. I think it's _all_ about
memory pressure, and you think it is _not_ about accounting for memory
pressure. :) Pe
Hi,
Could someone please to help with next question:
Where Linux (or maybe tty layer) keeps termios data?
If I run stty command, where stty gets current termios settings?
Thank you
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
>> isnt this patented by MS? (which might not worry you SuSE/Novell guys,
>> but it might be a worry for the rest of the world ;-)
On Fri, Mar 23, 2007 at 11:32:44AM +0100, Nick Piggin wrote:
> Hmm, it looks like they have implemented a
[ Andrew: This is the fixed-up, better-tested, with-Avi-suggestions
version. Please tell me if it still breaks something. Passes
allmodconfig with and without CONFIG_PARAVIRT, SMP and PREMPT here
against 2.6.21-rc4-mm1. ]
paravirt.c used to implement native versions of all low-level
functions.
Rusty Russell wrote:
4) Access to the native versions is trivial for KVM, lguest, Xen and
others who might want it.
kvm will be quite happy with it, as long as the x86_64 version has a
similar API.
include/asm-x86 anyone? ;-)
--
Do not meddle in the internals of kernels, for they are
On 3/23/07, Jack Malmostoso <[EMAIL PROTECTED]> wrote:
Hi there list,
this is a repost from the x86-64.org discuss list. I think it could be
relevant here too, if not please excuse me and forget this message. I am not
subscribed to the LKML, but I can follow the thread on usenet, so no need to
C
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote:
> afacit that two-year-old, totally-different patch has nothing to do with my
> repeatedly-asked question. It appears to be consolidating three separate
> quicklist allocators into one common implementation.
> In an attempt to answer m
On Fri, 2007-03-23 at 18:04 +0800, hutuworm wrote:
> Hi all,
>
> I just installed Red Hat Enterprise Linux AS release 4 (Nahant Update
> 4) on a Dell PE1950 server, which has two of dual-core Xeon 5110
> 1.6GHz CPUs. According to the processor spec @
> http://processorfinder.intel.com/details.aspx
It's happen only with 4G SD. I made the same test in 512Mb SD.
After suspend/resume there is no errors on fs.
If I resume PDA with 4G SD it go back to suspend after few seconds.
Rafael J. Wysocki wrote:
> On Thursday, 22 March 2007 13:35, Sergey Smirnov wrote:
>> I use 2.6.20.2 kernel with ext3 r
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote:
> afacit that two-year-old, totally-different patch has nothing to do with my
> repeatedly-asked question. It appears to be consolidating three separate
> quicklist allocators into one common implementation.
> In an attempt to answer m
Andrew Morton wrote:
but it crashes early in the page allocator (i386) and I don't see why. It
makes me wonder if we have a use-after-free which is hidden by the presence
of the quicklist buffering or something.
Does CONFIG_DEBUG_PAGEALLOC catch it?
--
SUSE Labs, Novell Inc.
Send instant mes
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger <[EMAIL PROTECTED]>
| Date: Tue Feb 27 12:13:00 2007 -0500
|
|ACPI: Only use IPI on known broken
On Fri, 2007-03-23 at 12:42 +0100, Ingo Molnar wrote:
> there's a new post-rc4 regression: my T60 hangs during early bootup. I
> bisected the hang down to this recent commit:
>
> | commit 25496caec111481161e7f06bbfa12a533c43cc6f
> | Author: Thomas Renninger <[EMAIL PROTECTED]>
> | Date: Tue Feb
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-config
>
> I don't know how to reproduce this bug on 2.6.21-rc4. On
> 2.6.21-rc2-mm1 it was very simple, just run youtube,
> bash_shared_mapping etc. In fact I didn't see th
Vivek Goyal napisał(a):
> On Thu, Mar 22, 2007 at 02:27:25PM +0100, Michal Piotrowski wrote:
>> Michal Piotrowski napisał(a):
>>> On 22/03/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
> 2.6.21-rc4-rt0
> BUG: at kernel/for
On Fri, 2007-03-23 at 16:59 +1100, Con Kolivas wrote:
>
> The deadline mechanism is easy to hit and works. Try printk'ing it.
I tried rc4-rsdl.33, and in a log that's 782kb, there is only one
instance of an overrun, which I created. On my box, it's dead code.
-Mike
-
To unsubscribe f
Hi!
> This supports the new clk_must_disable() interface for AT91 systems:
>
> - Implement the call, replacing at91_suspend_entering_slow_clock()
>and eliminating various "that's not exported" build warnings;
>
> - Use it in three drivers: USB Host, USB Peripheral, and RS232 serial.
>
> B
Nick Piggin <[EMAIL PROTECTED]> writes:
>> Would any of them work on a system on which every filesystem was on
>> ramfs, and there was no swap? If not then they are not memory attacks
>> but I/O attacks.
>>
>> I completely concede that you can DOS the system with I/O if that is
>> not limited as
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [ Ok, I think it's those timers again...
agreed - this seems to be a genuine CONFIG_HIGH_RES_TIMERS=y bug. (which
has probably not been fixed since -rc4 either, we have no bugfix in this
area that could explain the expires_next==KTIME_MAX timer sta
Andy Whitcroft wrote:
> Con Kolivas wrote:
>> On Friday 23 March 2007 05:17, Andy Whitcroft wrote:
>>> Ok, I have yet a third x86_64 machine is is blowing up with the latest
>>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with
>>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix le
Hi Andi
Checking Christoph quicklist implementation, I found the same cache miss in
free() than SLAB has.
/* common implementation *
int virt_to_nid(const void *addr)
{
struct page *page = virt_to_page(addr);
return page_to_nid(page);
}
On some platforms (x86_64 for example), c
On 3/23/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Checking Christoph quicklist implementation, I found the same cache miss in
free() than SLAB has.
/* common implementation *
int virt_to_nid(const void *addr)
{
struct page *page = virt_to_page(addr);
return page_to_nid(page);
}
Hello.
> > WARNING: mm/built-in.o - Section mismatch: reference to
> > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
> > offset 0x15c8f) and '__section_nr'
> I took a look at this one.
> You have SPARSEMEM enabled in your config.
> And then I see that in sparse.c we call all
Hi,
Sorry I haven't replied recently about that bug, but I have to admit I
have no idea where to start. There actually seems to be much more
fundamental problems with the kernel on my machines. I initially
realised that even without using suspend to RAM, I was still getting
crashes when docking. S
Eric Dumazet wrote:
> Some NUMA machines have a big MAX_NUMNODES (possibly 1024), but fewer
> possible nodes. This patch dynamically sizes the 'struct kmem_cache' to
> allocate only needed space.
>
> I moved nodelists[] field at the end of struct kmem_cache, and use the
> following computation in
Hi,
Thank you for your kind comments.
I'm still discussing the answer with my senior colleagues, so please
wait a few days. I think I can reply at the beginning of next week.
Best regards,
--
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory
Andrew Morton wrote:
> On Fri, 02 Mar 2
Hello !
Here's a minor fix for merge-sys_clone-sys_unshare-nsproxy-and-namespace.patch
dup_namespaces() does not exist any more, so we should remove the
declaration from nsproxy.h.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
include/linux/nsproxy.h |1 -
1 file changed, 1 dele
On Friday, 23 March 2007 10:14, Marcus Better wrote:
> Marcus Better wrote:
> > The XFS workqueue patch [1] fixes my problem [2].
>
> > [1] http://permalink.gmane.org/gmane.linux.kernel/507616
> > [2] http://permalink.gmane.org/gmane.linux.kernel/505570
>
> Unfortunately it only fixed suspend to
[Resend - this time with a comma in the addresses, not a dot]
Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> [ background: On ARM, SMP synchronisation does need barriers but device
> synchronisation does not. The question is that given this, whether
> mb() and friends can be NOPs on ARM or
On Fri, 23 Mar 2007 14:48:24 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On 3/23/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > Checking Christoph quicklist implementation, I found the same cache miss in
> > free() than SLAB has.
> >
> > /* common implementation *
> > int virt_to_nid(const
I posted this yesterday but it seems people didn't understand the real
goal of my patch. So I will explain once more again:
This is a bugfix for loop.c block driver, as it currently allocates more
memory then it needs, without any further use.
If 'max_loop=255' parameter is given, the loop.c
On Thu, Mar 22, 2007 at 09:29:05AM -0800, Andrew Morton wrote:
> On Thu, 22 Mar 2007 14:25:42 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > Additions and removal from tty_drivers list were just done as well as
> > iterating on it for /proc/tty/drivers generation.
> >
> > --- a/drivers/char/t
On Fri, Mar 23, 2007 at 07:47:50AM +0100, Blaisorblade wrote:
> Hey, I do like _these_ patches! A nice picture in that header could then be
> added (in the very future ;-) ), but at least one knows there are so much of
> them. And user_util.h is no more!
Heh :-)
user_util.h has disgusted me for
> But that is based on compile time option, isn't it? Perhaps I need
> to use some other mechanism to find out the platform is not NUMA capable..
We can probably make it runtime on x86. That will be needed sooner or
later for correct NUMA hotplug support anyways.
-Andi
-
To unsubscribe from this
On Thu, Mar 22, 2007 at 06:25:16PM -0700, Christoph Lameter wrote:
> On Thu, 22 Mar 2007, Siddha, Suresh B wrote:
>
> > > You should check num_possible_nodes(), or nr_node_ids (this one is
> > > cheaper,
> > > its a variable instead of a function call)
> >
> > But that is based on compile time
Setting the DEBUG_SIG flag breaks compilation due to a wrong
struct access. Aditionally, it raises two warnings. This is one
patch to fix them all.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
--
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"
commit ff9d841995b6055b7
> Rename boot_gdt_table to boot_gdt to avoid the duplicate
> T(able).
We already have so much code churn in this area now, please
no pointless renames for at least two releases.
Thanks.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Fri, Mar 23, 2007 at 12:15:12PM +0100, Eric Dumazet wrote:
> Hi Andi
>
> Checking Christoph quicklist implementation, I found the same cache miss in
> free() than SLAB has.
>
> /* common implementation *
> int virt_to_nid(const void *addr)
> {
> struct page *page = virt_to_page(addr);
On Fri, 23 Mar 2007, Tomas M wrote:
> This is a bugfix for loop.c block driver, as it currently allocates more
> memory then it needs, without any further use.
> If 'max_loop=255' parameter is given, the loop.c driver allocates this
> amount of memory:
> kmalloc(max_loop * sizeof(struct loop_d
On Fri, 23 Mar 2007 15:04:54 +0100
Tomas M <[EMAIL PROTECTED]> wrote:
> I posted this yesterday but it seems people didn't understand the real
> goal of my patch. So I will explain once more again:
>
> This is a bugfix for loop.c block driver, as it currently allocates more
> memory then it nee
On Fri, 23 Mar 2007, Eric Dumazet wrote:
> - if (max_loop < 1 || max_loop > 256) {
> - printk(KERN_WARNING "loop: invalid max_loop (must be between"
> - " 1 and 256), using default (8)\n");
> + if (max_loop < 1) {
> + printk(KERN_WARN
Jack Malmostoso wrote:
Hi there list,
this is a repost from the x86-64.org discuss list. I think it could be
relevant here too, if not please excuse me and forget this message. I am not
subscribed to the LKML, but I can follow the thread on usenet, so no need to
CC. Feel free to do it if you thi
On Fri, 23 Mar 2007 15:04:54 +0100 Tomas M <[EMAIL PROTECTED]> wrote:
>> I posted this yesterday but it seems people didn't understand the real
>> goal of my patch. So I will explain once more again:
>> This is a bugfix for loop.c block driver, as it currently allocates more
>> memory then it nee
On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote:
> On Fri, 23 Mar 2007 15:04:54 +0100
> Tomas M <[EMAIL PROTECTED]> wrote:
>
> > I posted this yesterday but it seems people didn't understand the real
> > goal of my patch. So I will explain once more again:
> >
> > This is a bugfix f
> Do you use the microcode driver?
No.
I'm in the middle of bisecting. Strange enough the symptoms change as I go.
Some commits manage to suspend to RAM, but hang at resume.
Marcus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
On Friday, 23 March 2007 00:30, Rafael J. Wysocki wrote:
> On Thursday, 22 March 2007 00:53, Rafael J. Wysocki wrote:
> > On Thursday, 22 March 2007 00:39, Maxim wrote:
> > > On Thursday 22 March 2007 01:24:25 Rafael J. Wysocki wrote:
> > > > On Thursday, 22 March 2007 00:09, Maxim wrote:
> > > > >
On Fri, Mar 23, 2007 at 03:04:54PM +0100, Tomas M wrote:
> I posted this yesterday but it seems people didn't understand the real
> goal of my patch. So I will explain once more again:
>
> This is a bugfix for loop.c block driver, as it currently allocates more
> memory then it needs, without an
On Fri, 23 Mar 2007 14:36:05 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote:
> > I cooked the following patch (untested), feel free to test it.
>
> Please, get the cleanup into saner shape. This is too ugly.
out_mem:
while (nba--)
Hi Ananth,
Here is a series of patches which introduce two kinds of interfaces
for speeding up unregistering process of kprobes.
Currently, the unregister_*probe() function takes a long time to
unregister specified probe because it waits the rcu synchronization
after each unregistration. So we ne
On Fri, Mar 23, 2007 at 02:41:09PM +, Christoph Hellwig wrote:
> The right thing to start with is to split the allocation up, and allocate
> each loop device by itself, like in the untested patch below:
>
> After that you're not wasting memory for any off number of loop devices
> and can creat
This patch introduces unregister_kretprobe_fast() for kretprobe.
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
include/linux/kprobes.h | 12 +++-
kernel/kprobes.c| 44
2 files changed, 39 insertions(+), 17 deletions(-)
On Fri, 23 Mar 2007, Eric Dumazet wrote:
> Checking Christoph quicklist implementation, I found the same cache miss in
> free() than SLAB has.
>
> /* common implementation *
> int virt_to_nid(const void *addr)
> {
> struct page *page = virt_to_page(addr);
> return page_to_nid(page);
This patch introduces unregister_jprobe_fast() for jprobe.
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
This patch introduces unregister_jprobe_fast() for jprobe.
include/linux/kprobes.h | 12 +++-
kernel/kprobes.c|6 --
2 files changed, 11 insertions(+),
On Fri, 23 Mar 2007 15:25:23 +0100 (CET)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Mar 2007, Eric Dumazet wrote:
>
> > - if (max_loop < 1 || max_loop > 256) {
> > - printk(KERN_WARNING "loop: invalid max_loop (must be between"
> > - " 1 and 256)
This patch adds the description of the fast unregisteration interfaces.
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
Documentation/kprobes.txt | 30 ++
1 file changed, 30 insertions(+)
Index: linux-2.6.21-rc4-mm1/Documentation/kprobes.txt
=
On Fri, 23 Mar 2007, Andy Whitcroft wrote:
> > + /*
> > +* We put nodelists[] at the end of kmem_cache, because we want to size
> > +* this array to nr_node_ids slots instead of MAX_NUMNODES
> > +* (see kmem_cache_init())
> > +* We still use [MAX_NUMNODES] and not [1] or [0] beca
HP Mobile Data Protection System 3D ACPI driver. Similar to hdaps in
functionality.
This driver provides 4 kinds of functionality:
1) Creates a misc device /dev/accel that acts similar to /dev/rtc and unblocks
the process reading from it when the device detects free-fall interrupt
2) Functions as
On Fri, Mar 23, 2007 at 03:48:09PM +0100, Eric Dumazet wrote:
> On Fri, 23 Mar 2007 14:36:05 +
> Al Viro <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Mar 23, 2007 at 03:19:56PM +0100, Eric Dumazet wrote:
> > > I cooked the following patch (untested), feel free to test it.
> >
> > Please, get the
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote:
>> afacit that two-year-old, totally-different patch has nothing to do with my
>> repeatedly-asked question. It appears to be consolidating three separate
>> quicklist allocators into one common implementation.
>> In an attempt to answ
On Thu, 22 Mar 2007, Christoph Hellwig wrote:
On Thu, Mar 22, 2007 at 03:42:27PM +, Mel Gorman wrote:
> A year ago, I may have agreed with you. However, Linus not only veto'd
> it but
> stamped on it repeatadly at VM Summit. He couldn't have made it clearer
> if
> he wore a t-shirt a hat an
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
> [... patch changing allocator alloc()/free() to bare page allocations ...]
> > but it crashes early in the page allocator (i386) and I don't see why. It
> > makes me wonder if we have a use-after-free which is hidden by the presence
> > of the q
Cornelia Huck wrote:
> On Thu, 22 Mar 2007 13:55:51 -0500,
> Larry Finger <[EMAIL PROTECTED]> wrote:
>> I applied the debug patch, but I don't see any error codes being returned.
>> This time I also got the
>> General Protection Faults. An excerpt of the log is attached.
>
> Hm, I think I have an
On Fri, 2007-03-23 at 12:56 +0100, Thomas Gleixner wrote:
> We should revert that patch and add a "trust_lapic_timer_in_c2"
> commandline option instead. So we are on the safe side.
Here is a patch which applies after reverting
25496caec111481161e7f06bbfa12a533c43cc6f
It turned out that it is al
On Fri, 23 Mar 2007, Ken Chen wrote:
On 3/21/07, Adam Litke <[EMAIL PROTECTED]> wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked about a character device that would
On Fri, Mar 23, 2007 at 01:44:38AM -0700, Ken Chen wrote:
> I think we have enough infrastructure currently in hugetlbfs to
> implement what Adam wants for something like a /dev/hugetlb char
> device (except we can't afford to have a zero hugetlb page since it
> will be too costly on some arch).
>
On Thu, 22 Mar 2007, Andrew Morton wrote:
> > About 40% on fork+exit. See
> >
> > http://marc.info/?l=linux-ia64&m=110942798406005&w=2
> >
>
> afacit that two-year-old, totally-different patch has nothing to do with my
> repeatedly-asked question. It appears to be consolidating three separate
On Thu, 22 Mar 2007, Stephane Eranian wrote:
> I ran into an issue with perfmon where I ended up calling
> kmalloc() with a size of zero. To my surprise, this did
> not return NULL but a valid data address.
>
> I am wondering if this is a property of kmalloc() or simply
> a bug. It is the case th
On Fri, 23 Mar 2007, Ken Chen wrote:
> >-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> >-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
> >addr,
> >-unsigned long len, unsigned long pgoff, unsigned long flags);
> >-#else
> >-static unsigned long
> >+unsigned long
>
1 - 100 of 315 matches
Mail list logo
