Jan Kasprzak napsal(a):
> Hello,
Hello.
> I have a MOXA C168H card, and after the upgrade from 2.6.19 to 2.6.21-rc6
> (and from moxa.c to mxser_new.c) I get a system lockup after few seconds
> of communicating over the MOXA serial line. Noting is printed on the
> serial console at all. The
Adrian Bunk wrote:
> Does CONFIG_HPET_TIMER=n make any difference?
Unfortunately not.
> Does the latest -git work?
Coming up next :)
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
To unsubscribe from this list: send the line "unsub
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Nick noticed that upon fork we change parent->wait_runtime but we do
> not requeue it within the rbtree.
this fix is not complete - because the child runqueue is locked here,
not the parent's. I've fixed this properly in my tree and have uploaded
a n
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >The CFS patch uses a completely different approach and implementation
> >from RSDL/SD. My goal was to make CFS's interactivity quality exceed
> >that of RSDL/SD, which is a high standard to meet :-) Testing
> >feedback is welcome to deci
Rene Herman <[EMAIL PROTECTED]> writes:
> Stumbling around with git here. I'd like to use git to efficiently
> track the current -stable as well as -current. Say, my local tree is a
> clone of Linus current:
>
> git clone \
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> l
I'm seeing this:
Apr 13 21:55:34 localhost kernel: BUG: sleeping function called from invalid
context at kernel/sched.c:3643
Apr 13 21:55:34 localhost kernel: in_atomic():1, irqs_disabled():0
Apr 13 21:55:34 localhost kernel: 1 lock held by events/0/8:
Apr 13 21:55:34 localhost kernel: #0: (dbs
fixed incorrect spinlock use in hysdn_log_close(). the function
declared a spinlock on the stack and used it to 'protect' a shared
driver structure. the patch removes the declaration of hysdn_lock and
uses card->hysdn_lock instead.
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
---
diff --
include KERN_* constant in printk() calls in arch/i386/mach-default/setup.c
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/mach-default/setup.c b/arch/i386/mach-default/setup.c
index c788162..f1891b6 100644
--- a/arch/i386/mach-default/setup.c
+++ b/arch/i386/mac
mod_sysfs_setup() doesn't return an errno when kobject_add_dir()
for module "holders" directory fails. So caller of mod_sysfs_setup()
will keep going and get oops.
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
Index: 2.6-mm/kernel/module.c
===
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
ye
Good day.
Stumbling around with git here. I'd like to use git to efficiently track the
current -stable as well as -current. Say, my local tree is a clone of
Linus current:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git local
I then branch off a 2.6.20 bra
Hello,
I have a MOXA C168H card, and after the upgrade from 2.6.19 to 2.6.21-rc6
(and from moxa.c to mxser_new.c) I get a system lockup after few seconds
of communicating over the MOXA serial line. Noting is printed on the
serial console at all. The system is SMP x86_64 (Fedora 5). I may b
Francis Moreau <[EMAIL PROTECTED]> wrote:
>
> Crypto core already seems to implement a priority mechanism. But I
> don't think I'm able to say "I'd like to use this algo for encrypting
> filesystems. If another part of the kernel wants to use this algo then
> give it the generic one". This choice
This removes an unneeded completion from kthread_create and moves
wake_up_process out of the kthread_create_lock making it clear that
wake_up_process doesn't need the protection of the
kthread_create_lock.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
kernel/kthread.c | 16 ++---
This patch reworks kthread_stop so it is more flexible and it causes
the target kthread to abort interruptible sleeps. Allowing a larger
class of kernel threads to use to the kthread API.
The changes start by defining TIF_KTHREAD_STOP on all architectures.
TIF_KTHREAD_STOP is a per process flag
On Fri, 13 Apr 2007 12:56:47 -0400, "Jeremy C. Andrus" <[EMAIL PROTECTED]>
wrote:
> I recently ran into a couple of USB devices which insisted on using 1024
> byte packets in bulk transfer mode (despite the hard limit of 512
> established in the spec). I really wanted to use these devices, so I
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>http://redhat.com/~ming
On Sat, 2007-04-14 at 02:38 +0200, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a
Mike Snitzer wrote:
On 4/13/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
Mike Snitzer wrote:
> On 2/2/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
>> Roland Dreier wrote:
>> > > They are mostly from Chuck Level and make preparating for IPv6
>> support
>> > > in the NFS server.
>> > > They are *no
Mike Snitzer wrote:
On 4/13/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
Mike Snitzer wrote:
> On 2/2/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
>> Roland Dreier wrote:
>> > > They are mostly from Chuck Level and make preparating for IPv6
>> support
>> > > in the NFS server.
>> > > They are *no
On Saturday 14 April 2007 01:28:20 Ravikiran G Thirumalai wrote:
> Provide a failsafe mechanism to avoid kernel spinning for ever at
> read_hpet_tsc
> during early kernel bootup.
>
> This failsafe mechanism was introduced in 21-rc,
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.gi
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Subject: i386: map enough initial memory to create lowmem mappings
>
> head.S creates the very initial pagetable for the kernel. This just
> maps enough space for the kernel itself, and an allocation bitmap.
> The amount of mapped memory is round
On 4/13/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
Mike Snitzer wrote:
> On 2/2/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
>> Roland Dreier wrote:
>> > > They are mostly from Chuck Level and make preparating for IPv6
>> support
>> > > in the NFS server.
>> > > They are *not* for 2.6.20, but sh
One other thing, what happens in the case of slow, frequency changing,
are/or inaccurate clocks .. Is the old sched_clock behavior still
tolerated?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote:
...
> git-acpi.patch
after bisecting I can finally say what breaks resume from STR here:
tada: CPU_IDLE.
I first spotted the git-acpi.patch then reapplied it and disabled
CPU_IDLE, now my laptop resumes.
Any useful information I
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> Where it gets complex is when the behavior patterns vary, e.g. they're
>> not entirely CPU-bound and their desired in-isolation CPU utilization
>> varies, or when nice levels vary, or both vary. [...]
On Sat, Apr 14, 2007 at 01:44:44AM +0200,
Just checking in after a few months of lurking. I have been running
2.6.18-rt7 for at least 4-5 months, possibly longer, without updates
and without problems.
Last weekend I updated my kernel for the first time in months. I must
say that while I cannot measure any differences the whole Gnome
envi
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> Linus Torvalds wrote:
>
> > We should be getting close to a 2.6.21 release, so please update any
> > regression reports you've done,
>
> For me, suspend to disk works only once (has been the case for all
> .21-rcs IIRC, but I did
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> It's a shame kthread_stop() (may take a while!) runs with a global semaphore
> held. With this patch kthread() allocates all neccesary data (struct kthread)
> on its own stack, globals kthread_stop_xxx are deleted.
Oleg so fare you patches have been in
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> Where it gets complex is when the behavior patterns vary, e.g. they're
> not entirely CPU-bound and their desired in-isolation CPU utilization
> varies, or when nice levels vary, or both vary. [...]
yes. I tested things like 'massive_intr.c'
On Friday April 13, [EMAIL PROTECTED] wrote:
> Before I go on, let me appologise. I don't really know what I hope to
> accomplish, beyond trying to garner thoughts (and support?) for the topic.
>
> Essentially: I want to use Linux and ZFS. I don't particularly care about
> licences
You may no
Ingo Molnar wrote:
* Gabriel C <[EMAIL PROTECTED]> wrote:
as usual, any sort of feedback, bugreports, fixes and suggestions
are more than welcome,
Compile error here.
ah, !CONFIG_SMP. Does the patch below do the trick for you? (I've also
updated the full patch at the cfs-sche
On Fri, 13 Apr 2007 15:54:33 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> After all this time, bdevs are still lowmem etc. Crying shame.
On Fri, Apr 13, 2007 at 04:32:42PM -0700, Andrew Morton wrote:
> One would need to hunt down every use of b_data in filesystems and switch
> them t
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> If kernel_thread(kthread) succeeds, kthread() can not fail on its path to
> complete(&create->started) + schedule(). After that it can't be woken because
> nobody can see the new task yet. This means:
>
> - we don't need tasklist_lock for find_task
From: "doctor raid" <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 16:02:01 -0700
> [1] kernel errors reporting unaligned access of memory
> [2] The following two lines iterate twice a piece, about once every 2
> minutes:
>
> Kernel unaligned access at TPC[79c344] arpt_do_table+0x3cc/0x640
>
On Fri, 13 Apr 2007 15:54:33 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 13, 2007 at 03:46:53PM -0700, Andrew Morton wrote:
> > It's just weird - it exploits internal knowledge of VFS behaviour, diddles
> > with pagecache within a fake disk strategy handler, etc.
> > Furth
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> A binomial heap would likely serve your purposes better than rbtrees.
>> It's faster to have the next item to dequeue at the root of the tree
>> structure rather than a leaf, for one. There are, of course, other
>> priority queue structures (
* Gabriel C <[EMAIL PROTECTED]> wrote:
> > as usual, any sort of feedback, bugreports, fixes and suggestions
> > are more than welcome,
>
> Compile error here.
ah, !CONFIG_SMP. Does the patch below do the trick for you? (I've also
updated the full patch at the cfs-scheduler URL)
Ingo
Provide a failsafe mechanism to avoid kernel spinning for ever at read_hpet_tsc
during early kernel bootup.
This failsafe mechanism was introduced in 21-rc,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2f7a2a79c3ebb44f8b1b7d9b4fd3a650eb69e544
But looks like the
Zhao Forrest wrote:
These 2 kernel options are turned on by default in my kernel. Here's
snip from .config
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
Does this fix it?
--- fs/buffer.c~2007
Chuck Ebbert wrote:
When I reboot my notebook, it powers off and powers back on.
On poweroff a loud snapping noise seems to be coming from the
hard drive. Today I noticed there is no "shutdown: hda" on
the console when I reboot. Whne I do a normal poweroff the
message is displayed and there is no
Before I go on, let me appologise. I don't really know what I hope to
accomplish, beyond trying to garner thoughts (and support?) for the topic.
Essentially: I want to use Linux and ZFS. I don't particularly care about
licences or any of the rest of that nonsense. The code is there; it merely
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >central tunable:
> >
> > /proc/sys/kernel/sched_granularity_ns
> >
> >which can be used to tune the scheduler from 'desktop' (low
> >latencies) to 'server' (good batching) workloads. It defaults to a
> >setting suitable for
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> Bartek wrote:
> > Hopefully, this time it my bug report should be ok :):
> >
> > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> kthread() sleeps in TASK_INTERRUPTIBLE state waiting for the first wakeup.
> In theory, this wakeup may come from freeze_process()->signal_wake_up(),
> so the task can disappear even before kthread_create() sets its ->comm.
>
> Change kthread() to use TA
Jerome, btw, in the future please fix your email client.
It added extra spaces and also deleted some in the patch,
making the patch not apply without a lot of hand-editing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
From: Jerome Borsboom <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 21:50:00 +0200 (CEST)
> When a VLAN interface is created on top of a bridge interface and
> netfilter is enabled to see the bridged packets, the packets can be
> corrupted when passing through the netfilter code. This is caused by
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> OK, I fixed that up.
>
> The next patch (make-kthread_stop-scalable) removes the find_task_by_pid()
> anyway.
Ok. Neat. I still need to review these a little more I have a different
set of criteria, but it is interesting work..
> Our kthread creation
Ingo Molnar wrote:
[announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
i'm pleased to announce the first release of the "Modular Scheduler Core
and Completely Fair Scheduler [CFS]" patchset:
http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch
[...]
Security fixes since 2.6.16.46:
- CVE-2007-1357: APPLETALK: Fix a remotely triggerable crash
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kerne
Thanks, applied to 2.6.16.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscri
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.47:
Hi.
On Sat, 2007-04-14 at 00:57 +0200, Rafael J. Wysocki wrote:
> > > > Well, I'm not sure. First, we don't really know what the value of it
> > > > should be
> > > > and this alone is a good enough reason for making it tunable, IMHO.
> > > > Second, I
> > > > think different systems may need
On Fri, Apr 13, 2007 at 03:46:53PM -0700, Andrew Morton wrote:
> > If I want to run a system entirely from ram with a compressed filesystem
> > image mounted on /, is it better to store that image in a ramdisk, or on
> > a tmpfs and mount it via loopback?
>
> Store it all in ramfs, no loopback nee
On Friday 13 April 2007 01:56:31 Oleg Nesterov wrote:
> usbatm_do_heavy_init() calls allow_signal() which plays with parent process's
> ->sighand.
>
> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Acked-by: Duncan Sands <[EMAIL PROTECTED]>
> --- 2.6.21-rc5/drivers/usb/atm/usbatm.c~usbatm
This is a note to let you know that I've just added the patch titled
Subject: PCI: add debug information to resource collision message
to my gregkh-2.6 tree. Its filename is
pci-add-debug-information-to-resource-collision-message.patch
This tree can be found at
http://www.kerne
On Saturday, 14 April 2007 00:45, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2007-04-14 at 00:40 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > > Well, it looks like someone allocated about 6000 pages after we
> > > > > > > had freed
> > > > > > > enough memory for suspending.
> > > > > >
>
On Fri, Apr 13, 2007 at 03:46:53PM -0700, Andrew Morton wrote:
> It's just weird - it exploits internal knowledge of VFS behaviour, diddles
> with pagecache within a fake disk strategy handler, etc.
> Furthermore, because it pretends to be a block device, the VFS will not use
> highmem pages when a
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler
> > [CFS]
> > i'm pleased to announce the first release of the "Modular Scheduler Core
> > and Completely
Andrew Morton [mailto:[EMAIL PROTECTED] wrote:
> On Fri, 13 Apr 2007 09:23:12 -0500
> Stephen Cameron <[EMAIL PROTECTED]> wrote:
>
> > Make cciss unconditionally include scsi/scsi.h
>
> For what reason?
Because the use of:
case SCSI_IOCTL_GET_IDLUN:
case SCSI_IOCTL_GET_BUS_NUMB
Mike Snitzer wrote:
On 2/2/07, Chuck Lever <[EMAIL PROTECTED]> wrote:
Roland Dreier wrote:
> > They are mostly from Chuck Level and make preparating for IPv6
support
> > in the NFS server.
> > They are *not* for 2.6.20, but should be ok for .21.
>
> Out of curiousity, does this patch series
Hi.
On Sat, 2007-04-14 at 00:40 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > > > freed
> > > > > > enough memory for suspending.
> > > > >
> > > > > We have a tunable allowance in Suspend2 for this, because fglrx
> >
On Fri, 13 Apr 2007 18:39:36 -0400
Jason Lunz <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 12, 2007 at 12:15:53PM -0700, Andrew Morton wrote:
> > All of ZONE_NORMAL got used by ramdisk, and networking wants to
> > allocate a page from ZONE_NORMAL. An oom-killing is the correct
> > response, although
Hi.
On Sat, 2007-04-14 at 00:38 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > > > freed
> > > > > > enough memory for suspending.
> > > > >
> > > > > We have a tunable allowance in Suspend2 for this, because fglrx
> >
On Friday 13 April 2007 1:51 pm, Francis Moreau wrote:
> Hi,
>
> I'm trying to port my old gpio code to the generic one to see if it
> can fit my needs.
Good .. this is more like an IRQ question though.
> The gpio controller is a home made one and has a really weird
> interface. It has several
H. Peter Anvin wrote:
Zachary Amsden wrote:
H. Peter Anvin wrote:
+/*
+ * End condition: we must map up to and including
+ * INIT_MAP_BEYOND_END bytes beyond the end of our
+ * own page tables; 0x1000 is the size of the page
+ * table were about to write, and +0x007 is the
+
On Thu, Apr 12, 2007 at 12:15:53PM -0700, Andrew Morton wrote:
> All of ZONE_NORMAL got used by ramdisk, and networking wants to
> allocate a page from ZONE_NORMAL. An oom-killing is the correct
> response, although probably not effective.
>
> ramdisk is a nasty thing - cannot you use ramfs or tm
Hi!
> > > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > > freed
> > > > > enough memory for suspending.
> > > >
> > > > We have a tunable allowance in Suspend2 for this, because fglrx
> > > > allocates a lot of pages in its suspend routine if DRI is enabled. I
>
On Sat, Apr 14, 2007 at 12:30:17AM +0200, Ingo Molnar wrote:
>
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I'm not in love with the current or other schedulers, so I'm
> > indifferent to this change. However, I was reviewing your release
> > notes and the patch and found myself wonder wh
Hi!
> > > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > > freed
> > > > > enough memory for suspending.
> > > >
> > > > We have a tunable allowance in Suspend2 for this, because fglrx
> > > > allocates a lot of pages in its suspend routine if DRI is enabled. I
>
Hi.
On Sat, 2007-04-14 at 00:35 +0200, Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 00:10, Pavel Machek wrote:
> > Hi!
> >
> > > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > > freed
> > > > > enough memory for suspending.
> > > >
> > > > We have a tun
On Fri, Apr 13, 2007 at 06:22:33PM -0400, Chuck Ebbert wrote:
> Greg KH wrote:
> >>>
> >>> The updated 2.6.20.y git tree can be found at:
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git
> >>> and can be browsed at the normal kernel.org git web browser:
>
Hi.
On Sat, 2007-04-14 at 00:10 +0200, Pavel Machek wrote:
> Hi!
>
> > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > freed
> > > > enough memory for suspending.
> > >
> > > We have a tunable allowance in Suspend2 for this, because fglrx
> > > allocates a lot of
On Saturday, 14 April 2007 00:10, Pavel Machek wrote:
> Hi!
>
> > > > Well, it looks like someone allocated about 6000 pages after we had
> > > > freed
> > > > enough memory for suspending.
> > >
> > > We have a tunable allowance in Suspend2 for this, because fglrx
> > > allocates a lot of pages
Hi Ingo,
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
(...)
>CFS's design is quite radical: it does not use runqueues, it uses a
>time-ordered rbtree to build a 'timeline' of future task executi
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> I'm not in love with the current or other schedulers, so I'm
> indifferent to this change. However, I was reviewing your release
> notes and the patch and found myself wonder what the logarithmic
> complexity of this new scheduler is .. I assumed it
Zachary Amsden wrote:
> H. Peter Anvin wrote:
>> +/*
>> + * End condition: we must map up to and including
>> + * INIT_MAP_BEYOND_END bytes beyond the end of our
>> + * own page tables; 0x1000 is the size of the page
>> + * table were about to write, and +0x007 is the
>> + *
Zachary Amsden wrote:
H. Peter Anvin wrote:
+/*
+ * End condition: we must map up to and including
+ * INIT_MAP_BEYOND_END bytes beyond the end of our
+ * own page tables; 0x1000 is the size of the page
+ * table were about to write, and +0x007 is the
+ * attribute bits.
H. Peter Anvin wrote:
+ /*
+* End condition: we must map up to and including
+* INIT_MAP_BEYOND_END bytes beyond the end of our
+* own page tables; 0x1000 is the size of the page
+* table were about to write, and +0x007 is the
+* attribute bits.
+
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>http://redhat.com/~mingo/cfs-
Greg KH wrote:
>>>
>>> The updated 2.6.20.y git tree can be found at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git
>>> and can be browsed at the normal kernel.org git web browser:
>>> www.kernel.org/git/
>> How long should that take to show up on
On Fri, 2007-04-13 at 22:21 +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>http://redhat.com/~mingo/cfs-s
On Fri, 2007-04-13 at 16:47 -0400, Mike Snitzer wrote:
> I must be missing something because I don't see _any_ trace of the
> core RPC over RDMA support (xprtrdma et al), your RPC Transport
> Switch, or any of the other supporting changes in mainline. Could
> you, or others, please clarify the pla
Hi!
> > > Well, it looks like someone allocated about 6000 pages after we had freed
> > > enough memory for suspending.
> >
> > We have a tunable allowance in Suspend2 for this, because fglrx
> > allocates a lot of pages in its suspend routine if DRI is enabled. I
> > think some other drivers do
On Fri, 13 Apr 2007 15:51:29 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > On Fri, 13 Apr 2007 17:02:01 +0400
> > Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> >> If kernel_thread(kthread) succeeds, kthread() can not fail on its path to
> >>
On Fri, Apr 13, 2007 at 05:54:33PM -0400, Chuck Ebbert wrote:
> Greg KH wrote:
> > We (the -stable team) are announcing the release of the 2.6.20.7 kernel.
> > This release has a number of bugfixes and any user of the 2.6.20 kernel
> > series is encouraged to upgrade.
> >
> > The diffstat and shor
Ingo Molnar napisał(a):
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
>
> i'm pleased to announce the first release of the "Modular Scheduler Core
> and Completely Fair Scheduler [CFS]" patchset:
>
>http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.pat
Greg KH wrote:
> We (the -stable team) are announcing the release of the 2.6.20.7 kernel.
> This release has a number of bugfixes and any user of the 2.6.20 kernel
> series is encouraged to upgrade.
>
> The diffstat and short summary of the fixes are below.
>
> I'll also be replying to this messa
-Original Message-
From: Len Brown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 1:33 AM
>Let me know if you have one that doesn't.
Sorry, please check this one.
YH
acpi_power_system_1.config
Description: acpi_power_system_1.config
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 13 Apr 2007 17:02:01 +0400
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
>> If kernel_thread(kthread) succeeds, kthread() can not fail on its path to
>> complete(&create->started) + schedule(). After that it can't be woken because
>> nobody can se
We just discovered that the accounting for initial memory usage
(head.S: INIT_MAP_BEYOND_END) has been way, way off for a very long
time. This patch makes the initial page table not round up to the
nearest 4M boundary, but instead stop dead (and zero the rest of the
final page table) as soon as it
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> and even adding all the scheduling modules, the total size impact is
> relatively small:
>
> 18 files changed, 1454 insertions(+), 1133 deletions(-)
>
> most of the increase is due to extensive comments. The kernel size
> impact is in fact a small n
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Thinking a bit more about this, I'm quite sure most users wouldn't
> > > even want private namespaces. It would be enough to
> > >
> > > chroot /share/$USER
> > >
> > > and be done with it.
> > >
> > > Private namespaces are only good for keep
Rafael J. Wysocki wrote:
>
> IMO to really fix the problem, we should let the drivers that need much memory
> for suspending allocate it _before_ the memory shrinker is called. For this
> purpose we can use notifiers that will be called before we start the shrinking
> of memory. Namely, if a dri
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> What I originally did did so for a good reason, which was that it was
> intended to support far more radical reorganizations, for instance,
> things that changed the per-cpu runqueue affairs for gang scheduling.
> I wrote a top-level driver
On Fri, Apr 13, 2007 at 02:21:10PM -0700, William Lee Irwin III wrote:
> On Fri, Apr 13, 2007 at 10:55:45PM +0200, Ingo Molnar wrote:
> > Yeah. Note that there are some subtle but crutial differences between
> > PlugSched (which Con used, and which i opposed in the past) and this
> > approach.
>
Andrew Morton <[EMAIL PROTECTED]> writes:
> jffs2 actually wants its head examined. W. T. F. does it think it's
> doing in there?
Good question, especially with respect to SIGHUP.
It is on my short list of very annoying kernel threads...
NFS and a few kernel threads others currently need a way
1 - 100 of 311 matches
Mail list logo
