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 body of a
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
wasting time.
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 have
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 [EMAIL
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
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 that
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
+++
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 support. Builds
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 from Linux, nor
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 system can
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 with slub_debug.
No
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 is
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
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
---
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, 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
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:
..
Ah ok, you need
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 PROTECTED]
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 is
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: Miklos Szeredi
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 2007, Badari
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
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 which
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.
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
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 was
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.
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.
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, 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 time
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 mmap()
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, 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]
---
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
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(), it
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.
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
===
---
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 -0700
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
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 anymore.
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, 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
+
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 or
HT irq
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 audio starts to
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 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 W.
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 we have a
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 reported by
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
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, 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 http://vger.kernel.org/majordomo-info.html
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
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
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
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 and then back to
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
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
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 without an
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' using the
[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
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
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 drm_fb since
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
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 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 PCI quirk
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 PROTECTED]
[EMAIL PROTECTED] wrote:
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
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
+/* lzo1x.h -- public interface of the LZO1X compression algorithm
+
+ This file is part of the LZO real-time data compression library.
+
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus
Jesper Juhl wrote:
Various other documents that are worth reading in the kernel source :
I have also compiled some helpful hints on how to get
source code accepted into the upstream kernel:
http://kernelnewbies.org/UpstreamMerge
The kernel-mentors mailing list is another useful
resource you
On May 18 2007 17:02, John Sigler wrote:
I'm getting disagrees about version of symbol struct_module messages,
and I'm trying to understand why.
As far as I understand (which is not very far), if I define
CONFIG_MODVERSIONS, then checksums for various functions (all exported
functions?)
From: Kumar Gala [EMAIL PROTECTED]
Date: Fri, 18 May 2007 11:31:19 -0500
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
On 05/18, Zilvinas Valinskas wrote:
On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote:
However, I can't understand why cleanup_workqueue_thread() hangs anyway.
It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU.
According
to kernel-nfs-freeze.log it is
Hi,
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be
done byte per byte (but it could be the expected behavior if there
unaligned access).
When I tested this on ARM, the output for
In article [EMAIL PROTECTED] you wrote:
Am I right that is chipset on mainboard, who is saying - I know, not
CPU itself?
It is a feature bitfield read directly from the CPU.
Is it better to switch off HT support in BIOS?
The CPU will still report that flag. Might speed up the boot, not
phantom, move to unlocked_ioctl
phantom's ioctl is often (4000 times a sec or so) invoked, don't acquire BKL
and block other processes.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 79b7336ec18e967de0026d2cc08de47da6333761
tree d180d46c4bf38ee42adf8949e9f746f893aae32b
parent
cleanup_workqueue_thread() and cwq_should_stop() are overcomplicated. Convert
the code to use kthread_should_stop/kthread_stop as was suggested by Gautham
and Srivatsa.
In particular this patch removes the (unlikely) busy-wait loop from the exit
path, it was a temporary and ugly kludge (if not a
On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
+
+static struct kmem_cache_ops ext2_kmem_cache_ops = {
+ ext2_get_inodes,
+ kick_inodes
+};
+
We love C99 names:
static struct kmem_cache_ops ext2_kmem_cache_ops = {
.get = ext2_get_inodes,
.kick = kick_inodes,
};
I wonder if there are other uses for the free space?
unsigned long moreflags;
Nick and Hugh were just sparring over adding a couple (or perhaps 8)
flag bits. This would supply 64 new bits ... maybe that would keep
them happy for a few more years.
-Tony
-
To unsubscribe from this list:
On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
Index: slub/mm/shmem.c
===
--- slub.orig/mm/shmem.c 2007-05-18 00:54:30.0 -0700
+++ slub/mm/shmem.c2007-05-18 01:02:26.0 -0700
Do we need *this*? (compare
On Fri, May 18, 2007 at 10:27:06PM +0200, Jan Engelhardt wrote:
On May 18 2007 17:02, John Sigler wrote:
I'm getting disagrees about version of symbol struct_module messages,
and I'm trying to understand why.
As far as I understand (which is not very far), if I define
Luca Tettamanti wrote:
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
Andrew Morton wrote:
aio is unlikely
Stick an unlikely() around is_aio(): I assert that most IO is
synchronous.
-#define in_aio() !is_sync_wait(current-io_wait)
+#define in_aio() (unlikely(!is_sync_wait(current-io_wait)))
Jeff Garzik [EMAIL PROTECTED] wrote:
-#define in_aio()
Make the bay driver send env information on bay events.
Upon any bay event, we will send the string BAY_EVENT=%d along with the
KOBJ_CHANGE, and report the event number. What the event number means will
be platform specific. Event 3 is always an eject request, but an insert
may be either
On Fri, 18 May 2007, Jan Engelhardt wrote:
On May 18 2007 11:10, [EMAIL PROTECTED] wrote:
+
+static struct kmem_cache_ops ext2_kmem_cache_ops = {
+ext2_get_inodes,
+kick_inodes
+};
+
We love C99 names:
static struct kmem_cache_ops ext2_kmem_cache_ops = {
.get =
On Fri, 18 May 2007, Jan Engelhardt wrote:
Do we need *this*? (compare procfs)
I believe that shmfs's inodes remain more in memory than those of
procfs. That is, procfs ones can find their way out (we can regenerate
it), while shmfs/tmpfs/ramfs/etc. should not do that (we'd lose the
file).
On Fri, 18 May 2007 22:34:53 +0200 (CEST)
Jiri Slaby [EMAIL PROTECTED] wrote:
@@ -118,7 +125,9 @@ static int phantom_ioctl(struct inode *inode, struct file
*file, u_int cmd,
if (r.reg 7)
return -EINVAL;
+ spin_lock(dev-ioctl_lock);
On Friday, May 18, 2007 12:33 pm Luca Tettamanti wrote:
Yeah, there's more sharing that could be done... though I don't
think the fb layer has the bits to actually grab EDIDs.
There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I
wrote them for the radeon driver, but now are
On 5/17/07, Ingo Molnar [EMAIL PROTECTED] wrote:
hey, cool! Also try -v13 - it should be even more tighter.
I tried -v13. However the scheduling error is now 10% (vs 2% with -v12).
I also noticed strange behaviour with CPU hotplug. I offlined cpu1
(echo 0 /sys/devices/system/cpu/cpu1/online),
On Fri, 18 May 2007 16:49:49 -0400
Alex Volkov [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
aio is unlikely
Stick an unlikely() around is_aio(): I assert that most IO is
synchronous.
-#define in_aio() !is_sync_wait(current-io_wait)
+#define in_aio()
601 - 700 of 773 matches
Mail list logo
