Seems there is an include of s390 based config in file
drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig"
The line doesn't seem to be need for an i386 build (haven't
tried x86_64 though).
I take it that this was a braino?
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, May 18, 2007 at 12:07:09PM -0700, Siddha, Suresh B wrote:
> On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
> > IIRC, the HT flag is also reported for multicore CPUs.
>
> Yes. Thats correct.
And for some Single-Core Non-HT CPUs.
Gruss
Bernd
--
(OO) -- [EMAIL
On Wed, May 09, 2007 at 08:36:54AM -0400, Jeff Garzik wrote:
> Henry Su wrote:
> > From: [EMAIL PROTECTED]
> > Adding the device ID for AMD/ATI SB700.
> > Signed-off-by:henry su <[EMAIL PROTECTED]>
>
> Time to train new people...
>
> You need to split up your patches:
> * send I2C and
On Thu, 17 May 2007, Frank Sorenson wrote:
> > Please boot with slub_debug.
>
> No debugging output at all. Still hangs with only:
> Kernel alive
> Kernel direct mapping tables up to 1 @ 8000-d000
H. No other output? Could it be that early console output is not
On Fri, 18 May 2007, Chris Snook wrote:
[EMAIL PROTECTED] wrote:
---
I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
that
Il Thu, May 17, 2007 at 06:04:54PM -0700, Jesse Barnes ha scritto:
> On Thursday, May 17, 2007, Luca Tettamanti wrote:
> > Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> > > This patch adds the core of the new DRM based modesetting system.
> >
> > A couple of comments on
On Fri, May 18, 2007 at 12:02:16PM -0700, Eric W. Biederman wrote:
> I will look closer but I do believe that from the ioapic to the cpu the 2.6.21
> code should be fairly robust with respect to inflight messages from the ioapic
> to the local apics and the cpus. What I failed to consider were
[EMAIL PROTECTED] wrote:
---
I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
that it has no HT feature, nor Windows XP identify
Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto:
> On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote:
> >
> > Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty,
> > git agrees and I've done a full rebuild. The .config is generated
> > using 'make oldconfig'
On Fri, 18 May 2007 20:01:54 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote:
>
> > ping?
>
> Noone disagreed, and trivial patches will be forwarded again during the
> 2.6.23 merge window.
Ok, I didn't know it would be acceptable
On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
> IIRC, the HT flag is also reported for multicore CPUs.
Yes. Thats correct.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
The glitch1 script has been vastly updated, and now runs by itself after
being started. It produces files with the fps from glxgears and a
"fairloops" file which indicates the number of loops for each of the
scrolling xterms. This gives a good indication of fairness, all
processes should have
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> On Fri, May 18, 2007 at 11:28:25AM -0700, Yinghai Lu wrote:
>> On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
>> >
>> > If the vector number stays same during irq migration and if we reset remote
>> > IRR bit using the above method(edge
The timerfd was using the unlocked waitqueue operations, but it was
using a different lock, so poll_wait() would race with it. This patch
makes timerfd directly use the waitqueue lock.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
Index: linux-2.6.mod/fs/timerfd.c
The eventfd was using the unlocked waitqueue operations, but it was
using a different lock, so poll_wait() would race with it. This patch
makes eventfd directly use the waitqueue lock.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
Index: linux-2.6.mod/fs/eventfd.c
On 18/05/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
For Dave: You can find the patchset also at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/slub-defrag
s/slub-defrag/slab-defrag
http://ftp.kernel.org/pub/linux/kernel/people/christoph/slab-defrag/
Regards,
Michal
--
Michal
On 5/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Fri, 18 May 2007 19:49:11 +0200 (CEST)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> cyclades, add firmware loading
[...]
The second patch fixes a bug in 2.6.22-rc1 and in 2.6.21 (yes?) but
I think, the bug is there since the driver merge
Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>> I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
>> everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
>> that it has no HT feature, nor Windows XP identify it as HT.
>
> the ht flag
On Fri, May 18, 2007 at 11:28:25AM -0700, Yinghai Lu wrote:
> On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> >
> > If the vector number stays same during irq migration and if we reset remote
> > IRR bit using the above method(edge and then back to level) during
> > irq migration, then
On Sat, May 19, 2007 at 01:06:49AM +0800, Eugene Teo wrote:
> NULL checks should be performed before the dereference.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
This does not apply against 2.6.22-rc1. Please rediff and repost.
Thanks,
John
--
John
> That doesn't do much to inprove overall readability.
>
> I suspect the warning was only there because the stubbed version of
> setup_nr_node_ids() forgot to be declared static inline, yes?
>
> How about this?
Yes, looks good.
Thanks,
Miklos
-
To unsubscribe from this list: send the line
On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
If the vector number stays same during irq migration and if we reset remote
IRR bit using the above method(edge and then back to level) during
irq migration, then we have a problem. A new interrupt arriving on a new
cpu will set the remote
For Dave: You can find the patchset also at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/slub-defrag
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Rats. Missing a piece due to the need to change the parameters of
kmem_zone_init_flags (Isnt it possible to use kmem_cache_create
directly?).
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: slub/fs/xfs/xfs_vfsops.c
===
On Fri, May 18, 2007 at 03:16:45AM -0400, Rob Landley wrote:
> Because the controller's far more likely to go than the moving parts...
Having redundant everything would be preferable. But cables do
sometimes fail. Not sure about the controllers, but if the controller
went you might loose the
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 5/18/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> We can solve the problem without doing that, and keeping the same
>> vector number during migration keeps x86 from scaling.
>
> I mean ioapic level irq couls be limited. new device could use MSI
On Friday 18 May 2007 15:56:07 Ingo Molnar wrote:
> * Anant Nitya <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > Been testing this version of CFS from last an hour or so and still
> > facing same lag problems while browsing sites with heavy JS and or
> > flash usage. Mouse movement is pathetic and
On Fri, 18 May 2007, Eric Dumazet wrote:
> table = (void*) __get_free_pages(GFP_ATOMIC, order);
ATOMIC? Is there some reason why we need atomic here?
> + /*
> + * If bucketsize is not a power-of-two, we may free
> +
On Fri, 18 May 2007, Nick Piggin wrote:
> However we don't have to let those 8 bytes go to waste: we can use them
> to store the virtual address of the page, which kind of makes sense for
> 64-bit, because they can likely to use complicated memory models.
That is not a valid consideration
On Fri, 18 May 2007, Nick Piggin wrote:
> The page->virtual thing is just a bonus (although have you seen what
> sort of hoops SPARSEMEM has to go through to find page_address?! It
> will definitely be a win on those architectures).
That is on the way out. See the discussion on virtual memmap
On Fri, 18 May 2007 19:49:11 +0200 (CEST)
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> cyclades, add firmware loading
>
eww, it adds a variable called "tmp".
This change isn't appropriate to 2.6.22.
The second patch fixes a bug in 2.6.22-rc1 and in 2.6.21 (yes?) but
includes irrelevant changes
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
net/socket.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
Index: slub/net/socket.c
===
--- slub.orig/net/socket.c 2007-05-18 00:54:30.0
Slab defragmentation occurs when the slabs are shrunk (after inode, dentry
shrinkers have been run from the reclaim code) or when a manual shrinking
is requested via slabinfo. During the shrink operation SLUB will generate a
list of partially populated slabs sorted by the number of objects in use.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/ext2/super.c | 16 ++--
fs/ext3/super.c | 14 +-
fs/ext4/super.c | 15 ++-
3 files changed, 41 insertions(+), 4 deletions(-)
Index: slub/fs/ext2/super.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/shmem.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
Index: slub/mm/shmem.c
===
--- slub.orig/mm/shmem.c2007-05-18 00:54:30.0
This patch allows the removal of unused or negative dentry entries in a
partially populated slab page.
get() uses the dcache lock and then works with dget_locked to obtain a
reference to the dentry. An additional complication is that the dentry
may be in process of being freed or it may just have
Add inode defrag support
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/reiserfs/super.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
Index: slub/fs/reiserfs/super.c
===
---
Hugh: Could you have a look at this? There is lots of critical locking
here
Support for Slab defragmentation and targeted reclaim. The current
state of affairs is that a large portion of inode and dcache slab caches
can be effectively reclaimed. The remaining problems are:
1. We cannot
Hmmm... Do we really need this?
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/proc/inode.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
Index: slub/fs/proc/inode.c
===
---
This implements the ability to remove a list of inodes from the inode
cache. In order to remove an inode we may have to write out the pages
of an inode, the inode itself and remove the dentries referring to the
node.
Provide generic functionality that can be used by filesystems that have
their
Add slab defrag support.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/kmem.h |5 +++--
fs/xfs/linux-2.6/xfs_buf.c |2 +-
fs/xfs/linux-2.6/xfs_super.c | 13 -
3 files changed, 16 insertions(+), 4 deletions(-)
Index:
We use the parameter formerly used by the destructor to pass an optional
pointer to a kmem_cache_ops structure to kmem_cache_create.
kmem_cache_ops is created as empty. Later patches populate kmem_cache_ops.
Create a KMEM_CACHE_OPS macro that allows the specification of a the
kmem_cache_ops.
Eric,
On Fri, May 18, 2007 at 07:40:53AM -0700, Eric W. Biederman wrote:
> Still in any of those I don't see a problem with switching to edge
> triggered mode and then back again. Either Remote IRR will keep
> it's current state or it will be cleared. Remote IRR should not
> get set (when it
On 5/18/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
We can solve the problem without doing that, and keeping the same
vector number during migration keeps x86 from scaling.
I mean ioapic level irq couls be limited. new device could use MSI or
HT irq directly and less irq routing problem.
Hi Nicolas,
> + info->fix.line_length = info->var.xres_virtual *
> (info->var.bits_per_pixel / 8);
line_length will always be 0 for bits_per_pixel < 8.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> Eric,
>
> ioapic_level irq is limited, So if we keep vector number not changed
> when imgration to other cpus. It that could help.
We can solve the problem without doing that, and keeping the same
vector number during migration keeps x86 from scaling.
First, please send all wireless patches to
[EMAIL PROTECTED], and be sure to CC me as well...thanks!
On Sat, May 19, 2007 at 12:50:31AM +0800, Eugene Teo wrote:
> libertas_upload_rx_packet() calls netif_rx() before returning, and it always
> return 0.
> Also within libertas_upload_rx_packet(),
This should be sent to linux-wireless (and CC'ed to me) as well...
On Sat, May 19, 2007 at 01:06:49AM +0800, Eugene Teo wrote:
> NULL checks should be performed before the dereference.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
>
> diff --git
On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote:
> ping?
Noone disagreed, and trivial patches will be forwarded again during the
2.6.23 merge window.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of
On Fri, 18 May 2007 12:39:14 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> This is now the only (!) compiler warning I get in my UML build :)
>
>
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> mm/page_alloc.c:931: warning: 'setup_nr_node_ids' defined but not used
>
> Signed-off-by:
In article <[EMAIL PROTECTED]> you wrote:
> I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid,
> everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out
> that it has no HT feature, nor Windows XP identify it as HT.
the ht flag reported by the CPU and cpuinfo
On Fri, 2007-05-18 at 09:35 +0200, Jens Axboe wrote:
> On Thu, May 17 2007, Badari Pulavarty wrote:
> > On Thu, 2007-05-17 at 08:27 +0200, Jens Axboe wrote:
> > > On Wed, May 16 2007, Badari Pulavarty wrote:
> > > > On Tue, 2007-05-15 at 19:50 +0200, Jens Axboe wrote:
> > > > > On Tue, May 15
On Fri, 2007-05-18 at 19:03 +0200, Jens Axboe wrote:
> On Fri, May 18 2007, Badari Pulavarty wrote:
> > On Fri, 2007-05-18 at 09:33 +0200, Jens Axboe wrote:
> > > On Thu, May 17 2007, Badari Pulavarty wrote:
> > > > On Thu, 2007-05-17 at 08:27 +0200, Jens Axboe wrote:
> > > > ..
> > > > > > >
>
cyclades, fix sparse warning
+ one possible deadlock (omitted unlock)
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit a9dbc0b98956d548b1aee3f55b3799a12946ace4
tree 1e62235a9bf1edb7c206932c9a10d1e9e77cb0a0
parent 7a9aa4781fc5aa6493bb3a7ac59b3c9e5f20fa76
author Jiri Slaby <[EMAIL
On Fri, 18 May 2007 22:52:15 +0530, Anand Jahagirdar said:
> output is 8050. when root or any other user changes ulimit by typing
> "ulimit -u value",.ulimit value is changed for that session and not
> permantely.
Right. That value is only applied to that process, and its children. Or more
cyclades, add firmware loading
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 7a9aa4781fc5aa6493bb3a7ac59b3c9e5f20fa76
tree 18d85e52a13cd780cf808a43d68b569a8546e2ab
parent 4ea1257b890befc706f6d43562ba68671db39195
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 18 May 2007 18:45:35 +0200
On Fri, 2007-05-18 at 14:04 +0400, Pavel Emelianov wrote:
> This includes /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes
> entries.
>
> Both need to show the header and use the list_head.
>
> Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Acked-by: Trond Myklebust <[EMAIL PROTECTED]>
>
Richard Purdie wrote:
On Wed, 2007-05-16 at 10:06 -0700, Andrew Morton wrote:
On Wed, 16 May 2007 18:00:43 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote:
On Wed, 2007-05-16 at 09:50 -0700, Randy Dunlap wrote:
On Tue, 15 May 2007 20:19:14 -0700 Andrew Morton wrote:
On Thu, 17 May 2007 22:24:11 +0200 (CEST)
Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> This patch is using mmap()'s randomization functionality in such a way
> that it maps the main executable of (specially compiled/linked -pie/-fpie)
> ET_DYN binaries onto a random address (in cases in which
Eric,
ioapic_level irq is limited, So if we keep vector number not changed
when imgration to other cpus. It that could help.
it will need modify a little with assign_irq_vector and
irq_complete_move/smp_irq_move_cleanup_interrupt. because it assume
vector must be changed.
YH
-
To unsubscribe
On Fri, 18 May 2007 12:01:41 EDT, "Robert P. J. Day" said:
> On Fri, 18 May 2007, debian developer wrote:
> > -your skills, and other developers will be aware of your presence. Fixing
> > bugs is one of the best ways to get merits among other developers, because
> > not many people like wasting
Hello All
I found one more interesting thing related with fork
bombing attack. i have set following in /etc/security/limits.conf file
[EMAIL PROTECTED]hard nproc 3000
[EMAIL PROTECTED] hard nproc 500
I have tried to execute fork bombing program on the same machine. it
Peter wrote:
> cpusets are ignored when in dire straights for an kernel alloc.
No - most kernel allocations never ignore cpusets.
The ones marked NOFAIL or ATOMIC can ignore cpusets in dire straights
and the ones off interrupts lack an applicable cpuset context.
--
I won't
On Fri, 18 May 2007, Peter Zijlstra wrote:
> On Thu, 2007-05-17 at 15:27 -0700, Christoph Lameter wrote:
> Isn't the zone mask the same for all allocations from a specific slab?
> If so, then the slab wide ->reserve_slab will still dtrt (barring
> cpusets).
All allocations from a single slab
Protect the header file include/linux/console_struct.h against
multiple inclusion, since not doing this causes one of the example
module programs in the Linux Kernel Module Programming Guide to fail
to build due to a bogus "redeclaration" of some structures.
Signed-off-by: Robert P. J. Day
Hi there brave visitor from the future ;)
Andi Kleen wrote:
> Actually that's not correct. With panic=30 and lilo -R and a working
> backup kernel a system can recover from this. With your endless loop it can't.
>
> Always add some kind of timeout.
>
>
Did you check the second version? Is
NULL checks should be performed before the dereference.
Spotted by the Coverity checker.
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/libertas/fw.c
b/drivers/net/wireless/libertas/fw.c
index 441123c..5c63c9b 100644
--- a/drivers/net/wireless/libertas/fw.c
+++
ping?
On Fri, 11 May 2007 22:05:01 -0400
Matt LaPlante <[EMAIL PROTECTED]> wrote:
> Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15.
>
> Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>
> --
>
> diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
> ---
Hello dear developers!
Here is my system configuration.
Linux ns 2.6.19-gentoo-r5 #5 SMP Thu May 3 00:45:12 AMST 2007 i686
Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux
Gnu C 4.1.1
Gnu make 3.81
binutils 2.16.1
util-linux
On Fri, May 18 2007, Badari Pulavarty wrote:
> On Fri, 2007-05-18 at 09:33 +0200, Jens Axboe wrote:
> > On Thu, May 17 2007, Badari Pulavarty wrote:
> > > On Thu, 2007-05-17 at 08:27 +0200, Jens Axboe wrote:
> > > ..
> > > > > >
> > > > > > Ah ok, you need the updated patch series for ppc64
On Fri, 18 May 2007, H. Peter Anvin wrote:
young dave wrote:
Hi,
After installation the new mm1 kernel, My system can not boot, the rc1
kernel works ok.
The cursor just blinks after appearing "Bios data check successful"
message.
what do you think about this?
"Bios data check successful"
Pierre Ossman <[EMAIL PROTECTED]> writes:
>
> If the device never shows up than we will hang in an infinite loop.
> Previously we panic:ed instead, so this behaviour should be no
> worse.
Actually that's not correct. With panic=30 and lilo -R and a working
backup kernel a
On Thu, 17 May 2007, Frank Sorenson wrote:
> >> I've tracked down this hang to a kzalloc in the hpet code that never
> >> returns. But only when using SLUB. Using SLAB, the highres/dyntick
> >> patch boots without problem.
> >>
> >> ...adding Christoph to the CC list...
> >
> > Please boot
young dave wrote:
> Hi,
>
> After installation the new mm1 kernel, My system can not boot, the rc1
> kernel works ok.
>
> The cursor just blinks after appearing "Bios data check successful"
> message.
>
> what do you think about this?
"Bios data check successful" is not a message that comes
Thomas Gleixner wrote:
> On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
>> I asked this earlier, but figured you might have a better insight.
>> Is their value in having 'drivers' for more than one clock source?
>> I'd say most (of not all) the PPC SoCs have timers on the system side
libertas_upload_rx_packet() calls netif_rx() before returning, and it always
return 0.
Also within libertas_upload_rx_packet(), it will initialize skb->protocol
anyways.
Spotted by the Coverity checker.
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
diff --git
Kumar Gala wrote:
>
> On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
>
>> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
>>>
>>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
>>> easily.
>>
>> There is some basic work for MPC5200 available:
>>
>>
On Fri, 2007-05-18 at 11:31 -0500, Kumar Gala wrote:
> I asked this earlier, but figured you might have a better insight.
> Is their value in having 'drivers' for more than one clock source?
> I'd say most (of not all) the PPC SoCs have timers on the system side
> that we could provide
In article <[EMAIL PROTECTED]> you wrote:
>> bugs is one of the best ways to get merits among other developers, because
>> not many people like wasting time fixing other people's bugs.
> ^^^
>
> you might want to find a less demeaning term for debugging than
>
In article <[EMAIL PROTECTED]> you wrote:
> + printk(KERN_INFO
> + "out of virtual memory for process %d (%s): total_vm=%lu,
> uid=%d\n",
> + current->pid, current->comm, total_vm, current->uid);
And align this one with the print_fatal layout:
In article <[EMAIL PROTECTED]> you wrote:
>printk("%s/%d: potentially unexpected fatal signal %d.\n",
>current->comm, current->pid, signr);
can we have both KERN_WARNING please?
Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
I guess the real question is, how high resolution does a high
resolution
timer need to be,
In the order of microseconds.
I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil
> From: Cornelia Huck [mailto:[EMAIL PROTECTED]
> Finer granularity is certainly better here, but I'm not quite sure if
> this solves our s390 problem (we don't have dma support). All those
> backends should also have a non-dma version...
In fact that is already there. Here is the form of
On Fri, 2007-05-18 at 11:06 -0400, Ben Collins wrote:
> (Rediffed against latest git)
Added error check for ata_dev_read_id (Thanks tj)
Also, since hpa is disabled by default, print the native size, even when
HPA isn't asked for (so users and developers can know that it may need
to be used).
Andrea Righi wrote:
> Robin Holt wrote:
>> On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
>>> Rik van Riel wrote:
Andrea Righi wrote:
> I'm looking for a way to keep track of the processes that fail to
> allocate new
> virtual memory. What do you think about the
On Fri, May 18, 2007 at 03:51:26PM +0100, Richard Purdie wrote:
> A further cleanup of the kernel LZO library headers which untangles and
> removes ~400 lines of defines. This doesn't change the core minilzo code
> so diffability is maintained.
You should just throw away that. Guptas
On Fri, 18 May 2007, debian developer wrote:
...
> -Managing bug reports
> -
> -
> -One of the best ways to put into practice your hacking skills is by fixing
> -bugs reported by other people. Not only you will help to make the kernel
> -more stable, you'll learn to fix real
On Fri, 2007-05-18 at 09:33 +0200, Jens Axboe wrote:
> On Thu, May 17 2007, Badari Pulavarty wrote:
> > On Thu, 2007-05-17 at 08:27 +0200, Jens Axboe wrote:
> > ..
> > > > >
> > > > > Ah ok, you need the updated patch series for ppc64 support. Builds
> > > > > fine
> > > > > here on ppc64. See
On Fri, May 18, 2007 at 12:09:38AM -0400, Ed Sweetman wrote:
> the previous post i keep referring you to has a patch that was mangled
> ...here is the non-mangled version
>
> --- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
> 13:44:54.0 -0500
> +++
* Michael Lothian <[EMAIL PROTECTED]> wrote:
> Just thought I'd let you know that CFS is working on the PS3
heh, an important milestone i think =B-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Robin Holt wrote:
> On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
>> Rik van Riel wrote:
>>> Andrea Righi wrote:
I'm looking for a way to keep track of the processes that fail to
allocate new
virtual memory. What do you think about the following approach
Hello.
Daniel Walker wrote:
Well, the decrementer frequency may change, at least in theory (if the bus
clock changes).
Does that happen very often?
Never, I hope. :-)
Daniel
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi,
while playing around with powertop, I noticed that my power usage wasn't
what it used to be. In total idle mode, everything was fine, but as soon
as I loaded the ipw2200 module and bring up the device, power usage
rises to about 16.8W, while kernel up to 2.6.20 used only about 15.3W. A
day
On Fri, 18 May 2007, Nick Piggin wrote:
>
> If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
> which is quite a nice number for cache purposes.
>
> However we don't have to let those 8 bytes go to waste: we can use them
> to store the virtual address of the page, which
On Fri, 2007-05-18 at 19:06 +0400, Sergei Shtylyov wrote:
> Daniel Walker wrote:
>
> >>I haven't looked at all the new clock/timer code, is there any
> >>utility in having support for more than one clock source?
>
> > There is if the main clocksource has some issues where it can't be used.
>
I already have that stuff, but it only implements the decrementer (in fact
it's the patch submitted at the beginning of this thread).
I got it because I was far more interested in the GPIO handling..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Thomas Gleixner wrote:
On Fri, 18 May 2007 15:17:36 +0300 Zilvinas Valinskas <[EMAIL PROTECTED]> wrote:
> Have found this in dmesg (well earlier because of initcall_debug) I've
> never noticed that during boot (scrolls away too fast). Anyway -
>
> [7.841871] NetLabel: Initializing
> [7.841983] NetLabel:
On 5/18/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> * If RIPV is set it is not safe to restart, so set the 'no way out'
>flag rather than the 'kill it' flag.
Why? It is not PCC. We cannot return of course, but killing isn't returning.
My understanding is that the absence of RIPV
Just thought I'd let you know that CFS is working on the PS3
neutrino boot # dmesg
Using PS3 machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Starting Linux PPC64 #1 SMP Fri May 18 09:26:38 UTC 2007
-
ppc64_pft_size
On Fri, 18 May 2007 10:34:35 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> That shouldn't be a problem, libata default DMA mask is 32 bits (which
> >> isn't overridden with this controller) and so the block layer will
> >> bounce any data being read/written above that
101 - 200 of 773 matches
Mail list logo
