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
> 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:
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
* 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
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().
>
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
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
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
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
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,
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
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 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
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
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)
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
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 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,
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
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
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
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);
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.
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
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
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
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 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
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
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:
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
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
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
> 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
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:
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
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
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
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
>
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
>
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
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
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
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(-)
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,
> -
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
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 ++
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
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
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
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
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
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**
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
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
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
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 @@
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
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,
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
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:
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
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
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
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
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 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 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
>>
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
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
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
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
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 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
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
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
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 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
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
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
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)
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
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
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.
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
> On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
> > >
> > > The snowy is constant and abundant, and it seems to be independent of
> > > video size (640 through
> Quoting Andrew Morton <[EMAIL PROTECTED]>:
> Subject: Re: 2.6.21-rc1: T60 resume from suspend to RAM issues
>
> > On Fri, 23 Feb 2007 01:38:03 +0200 "Michael S. Tsirkin" <[EMAIL PROTECTED]>
> > wrote:
> > I tested this:
> > commit 9654640d0af8f2de40ff3807d3695109d3463f54
> > and see 2 issues:
On Sat, 24 Feb 2007, Ingo Molnar wrote:
> * Davide Libenzi wrote:
>
> > > +asmlinkage long
> > > +sys_threadlet_on(unsigned long restore_stack,
> > > + unsigned long restore_eip,
> > > + struct async_head_user __user *ahu)
>
> > > +asmlinkage long sys_threadlet_off(void)
>
>
On Sat, 24 Feb 2007, Michael K. Edwards wrote:
> The preceding may contain errors in detail -- I am neither a CPU
> architect nor an x86 compiler writer nor even a serious kernel hacker.
Ok, roger that. But why are you playing "Google & Preach" games to Ingo,
that ate bread and CPUs for the
On Fri, 2007-02-23 at 13:45 +0100, Ondrej Zajicek wrote:
> On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote:
> > On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
> > > This patch adds driver for S3 Trio / S3 Virge. Driver is tested
> > > with most versions of S3 Trio and
On Sat, 24 February 2007 09:32:49 -0800, Christoph Lameter wrote:
>
> If that is a problem for particular object pools then we may be able to
> except those from the merging.
How much of a gain is the merging anyway? Once you start having
explicit whitelists or blacklists of pools that can be
From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your
> system. There's
> > absolutely no need to build any of the additional modules.
> >
> Unfortunately what I'm
We don't have any users, and it is not so trivial to use NOAUTOREL works
correctly. It is better to simplify API.
Delete NOAUTOREL support and rename work_release to work_clear_pending to
avoid a confusion.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi !
looking at the Changelogs of the last 2.6.17 kernel and the
first 2.6.18 it is obvious that a lot happened in between - are
there some changelogs related to 2.6.18 development that are not found
at
On Sun, Feb 25, 2007 at 03:53:15AM +0900, Atsushi Nemoto wrote:
>
> This is a dirty hack to check all built-in.o just after linking
> vmlinux. But this can not detect mismatches in libs.a files, and
> modpost fails with "... is truncated" message on empty built-in.o
> files.
>
> Maybe checking
David Howells wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace equivalents
of double/triple faults.
My experience shows that there are only very rare occurrences of
situations where you cannot get
On Wed, 2007-02-21 at 20:34 +0900, Tejun Heo wrote:
> Kay Sievers wrote:
> > On 2/13/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> >> On Tue, 2007-02-13 at 17:04 +0100, Marcel Holtmann wrote:
> >> > > kernel BUG at lib/iomap.c:254!
> >> > > invalid opcode: [#1]
> >> > > ...
> >> > >
> >> > >
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.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=7995
> >
>
On 2/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> This is a fundamental misconception. [...]
> The scheduler, on the other hand, has to blow and reload all of the
> hidden state associated with force-loading the PC and wherever your
> architecture keeps its TLS (maybe not the whole TLB, but
it is definitely NOT my job to repair errors that other responsibility-free
people pushed into vanilla mainline without the slightest test effort in some
mm-tree for example. Who wasted it must repair it, without the slightest
discussion!
You're assuming the author didn't test it. For things
1 - 100 of 376 matches
Mail list logo
