---
Signed-off-by: <[EMAIL PROTECTED]>
---
Documentation/memctlr.txt | 70 ++
1 file changed, 70 insertions(+)
diff -puN /dev/null Documentation/memctlr.txt
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/Documentation/m
Hi,
My script could not parse the (#2) and posted the patches as subject
followed by "( " instead
I apologize,
Balbir Singh
-
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.
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
> Code looks OK. Not applied due to "for testing" note.
>
> General comment: it might be nice to do this in the core, just as a
> sanity check for a variety of problems, past, present and future.
We tried that with old IDE and all hell broke loose. Lo
I realise that this is not a question strictly related to development
of linux, but there have been changes related to sleep granularity
lately, and I'm assuming these changes are made with an idea of how
sleep functions are expected to be used from user space. Since some of
these changes h
On Tuesday 20 February 2007 1:10 pm, Jean Delvare wrote:
> Here is the naive patch I have come up with. It does the job, even
> though it is not clean by any means. But as you said, it's certainly not
> worse than the current state, so I hope we can still apply it.
One glitch I noticed: on drive
On Tuesday 20 February 2007 1:10 pm, Jean Delvare wrote:
>
> > There are probably good reasons (== deep hardware braindamage on older
> > systems that are now hard to find) for the strange init sequencing in
> > that code, but I can't see why they should prevent splitting out
> >
> > (a) devi
On Sat, 24 Feb 2007, Oleg Nesterov wrote:
> If my understanding correct, vmscan can find a page which lives in a already
> anon_vma_unlink'ed vma. This is ok, the page is pinned, and page->mapping is
> not cleared until free_hot_cold_page().
That's about right. The page_mapped checks, at several
On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
On Sat, 24 Feb 2007, Ingo Molnar wrote:
the on/off calls are shaped in a way that makes them ultimately
vsyscall-able - the kernel only needs to know about the fact that
we are in a threadlet (so that the scheduler can do its special
push-
On Fri, 23 Feb 2007, Paul E. McKenney wrote:
>
> This look like a valid fix to me, at least as long as the lock is never
> dropped in the meantime (e.g., to do I/O). If the lock -is- dropped in
> the meantime, then presumably whatever is done to keep the page from
> vanishing should allow an rcu_
From: Stefan Seyfried <[EMAIL PROTECTED]>
Fix the Oops occuring when SNAPSHOT_PMOPS or SNAPSHOT_S2RAM ioctl is called on
a system without pm_ops defined (eg. a non-ACPI kernel on x86 PC).
Signed-off-by: Stefan Seyfried <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
On Sat, 24 Feb 2007, Kyle Moffett wrote:
> On Feb 24, 2007, at 16:10:33, Davide Libenzi wrote:
> > On Sat, 24 Feb 2007, Ingo Molnar wrote:
> > > the on/off calls are shaped in a way that makes them ultimately
> > > vsyscall-able - the kernel only needs to know about the fact that we are
> > > in a
Jorg,
I am very found of all your comments and your positive attitude
on DualFS. I also understand that you have much more experience
than us in regard to GC and "cleaners". DualFS implementation is
using maybe old technology that can be definetly improved. Although
we understand the value of Dua
On Saturday, 24 February 2007 23:06, Rafael J. Wysocki wrote:
> From: Stefan Seyfried <[EMAIL PROTECTED]>
>
> Fix the Oops occuring when SNAPSHOT_PMOPS or SNAPSHOT_S2RAM ioctl is called on
> a system without pm_ops defined (eg. a non-ACPI kernel on x86 PC).
>
> Signed-off-by: Stefan Seyfried <[EM
Hi Ingo,
On 23/02/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Michal,
* Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Here is more
>
> hardirqs last enabled at (30787): [] syscall_exit_work+0x11/0x26
> hardirqs last disabled at (30788): [] ret_from_exception+0x9/0xc
> softirqs last enabled
On Sat, Feb 24, 2007 at 10:04:04PM +, Hugh Dickins wrote:
> On Sat, 24 Feb 2007, Oleg Nesterov wrote:
>
> Have you checked through the SLAB_DESTROY_BY_RCU end in slab.c?
> Is what that's doing still valid?
The only thing I see needed due to PREEMPT_RCU is the following comment
change.
For a t
On Fri, Feb 23, 2007 at 08:24:44PM -0800, William Lee Irwin III wrote:
>> You would be better served by a data structure different from a hashtable.
On Sat, Feb 24, 2007 at 06:09:37AM +0100, Nick Piggin wrote:
> Out of curiosity, what better data structure do you have in mind for
> the dentry hash
The machine is a Centrino laptop with an i810 card. So I guess those are
the responsible files:
drivers/char/drm/i810_*.c
drivers/video/i810/*
drivers/char/agp/i810*
and
drivers/char/drm/i915*
are most likely.. but it could be anything in the DRM or AGP subdirs..
perhaps two X.org logs
On Feb 23 2007 16:17, H. Peter Anvin wrote:
> Deepak Saxena wrote:
>>
>> diff --git a/lib/gen_crc32table.c b/lib/gen_crc32table.c
>> index bea5d97..ce447ff 100644
>> --- a/lib/gen_crc32table.c
>> +++ b/lib/gen_crc32table.c
>> @@ -1,6 +1,8 @@
>> # include
>> # include "crc32defs.h"
>> +#ifndef __
On 2/24/07, Davide Libenzi wrote:
Ok, roger that. But why are you playing "Google & Preach" games to Ingo,
that ate bread and CPUs for the last 15 years?
Sure I used Google -- for clickable references so that lurkers can
tell I'm not making these things up as I go along. Ingo and Alan have
ob
On Sat, Feb 24, 2007 at 10:10:57PM +, Hugh Dickins wrote:
> On Fri, 23 Feb 2007, Paul E. McKenney wrote:
> >
> > This look like a valid fix to me, at least as long as the lock is never
> > dropped in the meantime (e.g., to do I/O). If the lock -is- dropped in
> > the meantime, then presumably
Hi,
The pata_pcmcia problem is fixed. Thanks!
(I tested it on kernel 2.6.20-git14)
But kernel 2.6.20-mm2 introduced new oops
when I insert the pata_pcmcia device.
pcmcia: registering new device pcmcia1.0
SCSI subsystem initialized
libata version 2.10 loaded.
ata1: PATA max PIO0 cmd 0x0001d100 c
Hi Atsushi-san
On Sun, Feb 25, 2007 at 03:53:15AM +0900, Atsushi Nemoto wrote:
> On Thu, 22 Feb 2007 00:57:28 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]>
> wrote:
> > $ ../build-i386/scripts/mod/modpost ../build-i386/mm/built-in.o
> > WARNING: ../build-i386/mm/built-in.o - Section mismatch: r
On 12:11 Sat 24 Feb , Vojtech Pavlik wrote:
>
> That would be my only concern - losing compiler warnings.
yes
see
I wanted a single BIT macro which can be used by the whole tree
was looking for a multipurpose one. found it in input.h
so i thought i will put it at a common place
why bitops.h
Jan Engelhardt wrote:
On Feb 23 2007 16:17, H. Peter Anvin wrote:
Deepak Saxena wrote:
diff --git a/lib/gen_crc32table.c b/lib/gen_crc32table.c
index bea5d97..ce447ff 100644
--- a/lib/gen_crc32table.c
+++ b/lib/gen_crc32table.c
@@ -1,6 +1,8 @@
# include
# include "crc32defs.h"
+#ifndef __CYGWI
This patch removes the MAINTAINERS entry for the removed jffs
filesystem.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.20-mm2/MAINTAINERS.old2007-02-24 23:31:48.0 +0100
+++ linux-2.6.20-mm2/MAINTAINERS2007-02-24 23:32:04.0 +0100
@@ -1956,13 +1956,6 @@
On Sat, 24 Feb 2007, Hugh Dickins wrote:
> Two, in his SLUB thread it sounds like he's toying with mixing up kmem
> caches of similar sizes: that seems a really bad idea to me (for reasons
> Andi and others have made) and I expect it'll get dropped; but in case
> not, let's note that the anon_vma
On Sat, 24 Feb 2007, Jörn Engel wrote:
> How much of a gain is the merging anyway? Once you start having
> explicit whitelists or blacklists of pools that can be merged, one can
> start to wonder if the result is worth the effort.
It eliminates 50% of the slab caches. Thus it reduces the managem
This patch fixes a bug in Linux IPv6 stack which caused anycast address
to be added to a device prior DAD has been completed. This led to
incorrect reference count which resulted in infinite wait for
unregister_netdevice completion on interface removal.
Signed-off-by: Michal Wrobel <[EMAIL PRO
Ondrej Zary wrote:
On Saturday 24 February 2007 14:08, Chris Rankin wrote:
Hi,
I have just booted 2.6.20.1 on my Pentium 3 machine, which has a G400 MAX
graphics card. This machine uses the Matrox framebuffer and TV-OUT modules,
and I have found these warnings in the kernel log:
**WARNING** I2
From: Markku Savela <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 18:45:03 +0200
> I think that is worse than allow a new driver to provide a simple
> service function which maps IPv4/6 multicast address into link layer
> address, when asked.
The problem is that this mapping isn't so simple for seve
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 09:32:49 -0800 (PST)
> On Fri, 23 Feb 2007, David Miller wrote:
>
> > I also agree with Andi in that merging could mess up how object type
> > local lifetimes help reduce fragmentation in object pools.
>
> If that is a problem fo
From: William Lee Irwin III <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 14:56:31 -0800
> just do it on a per-directory basis so you don't intermix children
> of different parents in some boot-time -allocated global trainwreck
> and you're home free. Benchmarking is probably needed to gauge
> which
From: Michal Wrobel <[EMAIL PROTECTED]>
Date: Sun, 25 Feb 2007 01:13:59 +0100
> This patch fixes a bug in Linux IPv6 stack which caused anycast address
> to be added to a device prior DAD has been completed. This led to
> incorrect reference count which resulted in infinite wait for
> unregiste
On Thu, Feb 22, 2007 at 11:45:22AM -0500, Theodore Tso wrote:
>...
> The only way GPL'ed code can be become copyrighted by the FSF is if
> you explicitly sign a copyright statement
>...
And even this is only possible if permitted by copyright law.
E.g. German copyright law explicitely states tha
On Tue, Feb 13, 2007 at 11:55:10AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 21:35:59 -0500 (EST)),
> Pete Clements <[EMAIL PROTECTED]> says:
>
> > Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
> > > In article <[EMAIL PROTECT
On Sat, February 24, 2007 11:09 am, Andrew Morton wrote:
>> On Fri, 23 Feb 2007 13:35:50 - (GMT) "Andrew" <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>
>> 2.6.21-rc1 fails to boot on my machine. As soon as I switch
>> from grub the screen turns and remains black with no sign of Tux or any
>> output.
On Sat, February 24, 2007 11:09 am, Andrew Morton wrote:
>
> Presumably this regression was caused by the ACPI merge. Are you able to
> capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be
> useful here, thanks.
>
I've confirmed a few things:
1) 2.6.21-rc1 actually will boot
On Суббота 24 февраля 2007, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday, 24 February 2007 10:55, Andrey Borzenkov wrote:
> > On Вторник 13 февраля 2007, Andrey Borzenkov wrote:
> > > On Четверг 07 декабря 2006, Lebedev, Vladimir P wrote:
> > > > Please register new bug, attach acpidump and dmesg
On Sat, 2007-02-24 at 23:00 +, Andrew Nelless wrote:
> On Sat, February 24, 2007 11:09 am, Andrew Morton wrote:
> >
> > Presumably this regression was caused by the ACPI merge. Are you able to
> > capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be
> > useful here, thanks.
Hi Jeff,
I'll be resending the series of incremental patches originally submitted
on 02/22/07.
The series take in account Yoshifuji's comments.
Patch 2 - ioctl cleanup - is updated to secure backward compatibility.
The ioctls are now explicitly numbered.
Patch 6 is also updated with minor chan
From: Divy Le Ray <[EMAIL PROTECTED]>
sysfs attributes are now managed per port, no longer per adapter.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/cxg
From: Divy Le Ray <[EMAIL PROTECTED]>
Clean up some private ioctls.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_ioctl.h | 33 +--
drivers/net/cxgb3/cxgb3_main.c | 48 +++
2 files changed, 15 insertio
From: Divy Le Ray <[EMAIL PROTECTED]>
Improve the traffic recovery after the HW ran out of response queue entries.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |2 ++
drivers/net/cxgb3/sge.c | 15 ++-
2 files changed, 16 insertions(+), 1 d
From: Divy Le Ray <[EMAIL PROTECTED]>
Update FW version to 3.2
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 365a7f5..ec06ad6 1006
From: Divy Le Ray <[EMAIL PROTECTED]>
Add all-in-sw lro support.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 21 ++
drivers/net/cxgb3/common.h |1
drivers/net/cxgb3/cxgb3_ioctl.h |1
drivers/net/cxgb3/cxgb3_main.c | 16 ++
drivers/net
From: Divy Le Ray <[EMAIL PROTECTED]>
Offload packets may be DMAed long after their SGE Tx descriptors are done
so they must remain mapped until they are freed rather than until their
descriptors are freed. Unmap such packets through an skb destructor.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTE
From: Divy Le Ray <[EMAIL PROTECTED]>
Populate Rx free list with pages.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |9 +
drivers/net/cxgb3/sge.c | 318 +++
2 files changed, 235 insertions(+), 92 deletions(-)
d
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 23:50:21 +0100
> In the CONFIG_IPV6=m, CONFIG_SUNRPC=m case, this will result in no IPV6
> support here.
>
> If you are going this way, a Kconfig helper variable might be better:
>
> config SUNRPC_IPV6
> bool
> default y i
On Tue, Feb 20, 2007 at 12:43:41PM +0900, Tejun Heo wrote:
> Rafael J. Wysocki wrote:
> > Update:
> >
> > I get the same BUG with 2.6.20-git13 100% of the time during the resume.
> > The system seems to be fully functional nonetheless.
>
> Known bug, will be fixed soon.
Is this a variation of
S
Komuro wrote:
Hi,
The pata_pcmcia problem is fixed. Thanks!
(I tested it on kernel 2.6.20-git14)
But kernel 2.6.20-mm2 introduced new oops
when I insert the pata_pcmcia device.
pcmcia: registering new device pcmcia1.0
SCSI subsystem initialized
libata version 2.10 loaded.
ata1: PATA max PIO0
To a two-CPU architecture, its page distribution just like theoretically
ABABAB
So every readahead of A process will create 4 unused readahead pages unless you
are sure B will resume soon.
Have you ever compared the results among UP, 2 or 4-CPU?
-
To unsubscribe from this list: send the lin
> From: William Lee Irwin III <[EMAIL PROTECTED]>
> Date: Sat, 24 Feb 2007 14:56:31 -0800
>> just do it on a per-directory basis so you don't intermix children
>> of different parents in some boot-time -allocated global trainwreck
>> and you're home free. Benchmarking is probably needed to gauge
>
Pavel Machek wrote:
> Hi!
>
>> -stable review patch. If anyone has any objections, please let us know.
>>
>> --
>> From: Larry Finger <[EMAIL PROTECTED]>
>>
>> There is a kernel oops on bcm43xx when resuming due to an overly tight
>> timeout loop.
>>
>> Signed-off-by: Larry Finge
On Sat, Feb 24, 2007 at 02:12:29PM -0500, Chuck Ebbert wrote:
>
> Umm, it's already there, right after the word "Oops".
>
>
> Oops: 0002 [1] SMP
>
Oops! ;-)
--
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"
-
To unsubscribe from this list: send the line "unsubscribe
Hi Jörn,
On Fri, 23 Feb 2007, [utf-8] Jörn Engel wrote:
On Thu, 22 February 2007 20:57:12 +0100, Juan Piernas Canovas wrote:
I do not agree with this picture, because it does not show that all the
indirect blocks which point to a direct block are along with it in the
same segment. That figure
I'm an app programmer, not a kernel hacker. With that caveat...
I've been reading LWN article about AIO and the description of Linus' solution
and the following realization dawned on me: at its heart, the idea is to fork
when blocking. So let's make it explicit with a single new function call:
#d
Tejun Heo wrote:
ata_host_release() uses drvdata to determine ata_host to release and
clearing drvdata in ->remove_one causes NULL pointer deference. Clear
drvdata only in ata_host_release() after all resources are freed.
This bug was first analyzed by Alan Cox for pata_pcmcia.
Signed-off-by:
On Sat, 24 Feb 2007 20:45:18 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Any chance you could insert some printk() calls into ata_apci_exec_tfs?
> ata_exec_internal_sg() never calls that function, so I'm curious if
> something corrupted memory a bit, or what happened.
I insert some printk(
This patch is my first cut at converting sata_mv over to the new
libata EH stuff. It is completely untested, so be warned :)
If you are brave enough to test this, the test is simple: do your
disks appear, and work, the same as before (== without this patch)?
drivers/ata/sata_mv.c | 365 ++
On Sat, 24 Feb 2007 16:44:20 +0100 Mario Vanoni wrote:
> 2.6.18.7 vanilla & 2.6.16.41 vanilla:
> /dev/hda CD/DVD
> /dev/hda1 / IDE HD 160GB
> /dev/hda2 swap
> /dev/sda1 /xyz SATA HD 320GB
> /dev/sda2 swap
> /dev/sdb1 /zzz SATA HD 320GB
> /dev/sdb2 swap
> /dev/sdc1 /usb USB KEY 512MB
> all 100% OK
On Friday 16 February 2007, Con Kolivas wrote:
>This patchset is designed to improve system responsiveness and
> interactivity. It is configurable to any workload but the default -ck
> patch is aimed at the desktop and -cks is available with more emphasis
> on serverspace.
>
>Apply to 2.6.20
>http:
This patch implements deferred IO support in fbdev. Deferred IO is a way to
delay and repurpose IO. This implementation is done using mm's page_mkwrite
and page_mkclean hooks in order to detect, delay and then rewrite IO. This
functionality is used by hecubafb.
Thanks,
jaya
Signed-off-by: Jaya K
As I suspected, the one-shot code wasn't very well tested and I'd be
the one to debug this thing on sparc64 :-)
When a timer exceeds the timer period, the one-shot handling code does
the following loop:
for (;;) {
ktime_t next = ktime_add(dev->next_event, tick_period);
This patch implements support for the E-Ink/hecuba display device. It uses
deferred IO support.
Thanks,
jaya
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
---
hecubafb.c | 480 +
1 file changed, 480 insertions(+)
---
diff --git a/
Hello, Adrian.
Adrian Bunk wrote:
> On Tue, Feb 20, 2007 at 12:43:41PM +0900, Tejun Heo wrote:
>> Rafael J. Wysocki wrote:
>>> Update:
>>>
>>> I get the same BUG with 2.6.20-git13 100% of the time during the resume.
>>> The system seems to be fully functional nonetheless.
>> Known bug, will be fix
On Saturday 24 February 2007 06:11, Vojtech Pavlik wrote:
> > The reason I don't like it with modulo is simply because it hides
> > potential bugs (when x is to big).
>
> That would be my only concern - losing compiler warnings.
>
I think most dangerous scenario is when both shift operands are
On Saturday 24 February 2007 07:59, Richard Knutsson wrote:
> Vojtech Pavlik wrote:
> > On Fri, Feb 23, 2007 at 11:43:44PM +0100, Richard Knutsson wrote:
> >
> >
> >> Is the reason for the modulo to put a bitmask larger then the variable
> >> into an array?
> >>
> >
> > The complementary L
Hello!
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
box. The machine continued to run a few rounds of kernbench and LTP.
Looks a bit scary -- a tasklet was "stolen" from __tasklet_action().
Thoughts? In the meantime, kicking it off again to see if it repeats.
Just to clarify an apparent misunderstanding that has snuck into this
thread:
1) There are quite a few people/groups out there who are using TIPC's
socket API, so the protocol as a whole is being used and should remain
in the kernel.
2) There are portions of TIPC's native API which are intended f
On Sat, Feb 24, 2007 at 12:51:37PM +0100, Pavel Machek wrote:
> Hi!
>
> ...is it "use after free"?
>
> Greg, could we reduce verbosity of driver model? "PM: Adding info for
> No Bus:vcs*" is not very useful.
Maybe for you it isn't, but then again, you did enable
CONFIG_DEBUG_DRIVER to see that,
While getting dynticks/hrtimers up on sparc64 I ran into
the following build problem. If you use get_irq_regs() you
need to include asm/irq_regs.h
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 512a4a9..51556b9 100644
--
On Tue, Feb 20, 2007 at 03:15:55PM +, David Woodhouse wrote:
> > It would be much better to use __be32 and __be64, so you get better
> > type checking, and you will catch bugs caused by forgetting to use
> > be32_to_cpu, et. al.
>
> The technique Artem uses is derived from what I do in JFFS2.
On Tue, Feb 20, 2007 at 05:24:15PM +0200, Artem Bityutskiy wrote:
> On Tue, 2007-02-20 at 15:15 +, David Woodhouse wrote:
> > On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> > > It appears that the reason why you are doing this is because you think
> > > you need the (packed) attribute
On Tue, Feb 20, 2007 at 05:21:48PM +0200, Artem Bityutskiy wrote:
> > In that case it's not an *implementation* version number, but rather
> > an on-disk *format* version number.
>
> True, will refine the comment.
>
> > There's a difference. It's also
> > often not used much, since another way
On Tue, Feb 20, 2007 at 09:52:46AM -0500, John Stoffel wrote:
>
> Artem> This patch-set contains UBI, which stands for Unsorted Block
> Artem> Images. This is closely related to the memory technology
> Artem> devices Linux subsystem (MTD), so this new piece of software is
> Artem> from drivers/mtd
On Tue, Feb 20, 2007 at 03:05:53PM +0200, Artem Bityutskiy wrote:
> > Having this kind of global information directly exposed is a very
> > bad idea. In general you only want to access it through more
> > specific information and avoid allocating the global array at all.
>
> I do not see what is
On Mon, Feb 19, 2007 at 07:07:46PM +0200, Artem Bityutskiy wrote:
> > And when you create that many interfaces, it adds inertia to changing
> > the interfaces later on, because it's sometimes not clear how many
> > users of the interface there really are. My general rule of thumb is
> > that if an
On Mon, Feb 19, 2007 at 07:44:16PM +0200, Artem Bityutskiy wrote:
> On Mon, 2007-02-19 at 10:50 +, Christoph Hellwig wrote:
> > I think this is the wrong approach. For one thing the unit terms is
> > rather foregin in Linux
>
> I would rather disagree. Subjective. Unit is a generic word, just
On Tue, Feb 20, 2007 at 03:00:56PM +0200, Artem Bityutskiy wrote:
> > > +module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 000);
> > > +MODULE_PARM_DESC(mtd, "MTD devices to attach. Parameter format: "
> > > + "mtd=[,,]. "
> > > + "Multiple \"mtd\" parameters may b
On Sun, 2007-02-25 at 05:43 +, Christoph Hellwig wrote:
> > The technique Artem uses is derived from what I do in JFFS2. It predates
> > the use of sparse to catch such errors, and works in gcc for _everyone_
> > without having to do anything special (like run sparse).
>
> And makes the code c
On Fri, Feb 23, 2007 at 04:37:43PM +0100, Nick Piggin wrote:
>
> The dentry hash uses up 8MB for 1 million entries on my 4GB system is one
> of the biggest wasters of memory for me. Because I rarely have more than one
> or
> two hundred thousand dentries. And that's with several kernel trees wort
Hello!
This is an updated version of Oleg Nesterov's QRCU that avoids the
earlier lock acquisition on the synchronize_qrcu() fastpath. This passes
rcutorture on x86 and the weakly ordered POWER. A promela model of the
code passes as noted before for 2 readers and 3 updaters and for 3 readers
and
On Sat, Feb 24, 2007 at 09:02:12PM -0800, Paul E. McKenney wrote:
> Hello!
>
> I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
> box. The machine continued to run a few rounds of kernbench and LTP.
> Looks a bit scary -- a tasklet was "stolen" from __tasklet_action().
>
>
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
> Opteron box. The machine continued to run a few rounds of kernbench
> and LTP. Looks a bit scary -- a tasklet was "stolen" from
> __tasklet_action().
>
> Thoughts? In the meanti
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sun, 25 Feb 2007 07:27:47 +0100
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
> > Opteron box. The machine continued to run a few rounds of kernbench
> > and LTP. Looks a bit
> I gave it a quick try (must admit, not too tested) and it seems that
> the setting of TIF_SIGPENDING without really having a signal queued
> is not having easily visible ugly consequences.
what happens if you get a signal around the time the timeout fires?
-
To unsubscribe from this list: sen
On Sat, 24 Feb 2007 10:41:15 +0300, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Thanks a lot for comments and Ack the patch please.
Cyrill, I forgot to mention a couple of points, sorry.
> printk(KERN_INFO "driver %s built at %s on %s\n",
> ftdi_elan_driver.name,
> - _
Eric, you recommended to me that I use:
struct msi_desc *entry = get_irq_data(irq);
in my arch_teardown_msi_irq() routine earlier, but the current
code unlinks the entry before the call to arch_teardown_msi_irq()
so I get OOPS's on shutdown on sparc64 because of this since
get_irq_data()
101 - 188 of 188 matches
Mail list logo
