On Sun, 2007-04-15 at 13:27 +1000, Con Kolivas wrote:
> On Saturday 14 April 2007 06:21, 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
William Lee Irwin III 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 Fair Scheduler [CFS]" patchse
On Sun, Apr 15, 2007 at 01:27:13PM +1000, Con Kolivas wrote:
...
> Now that you're agreeing my direction was correct you've done the usual Linux
> kernel thing - ignore all my previous code and write your own version. Oh
> well, that I've come to expect; at least you get a copyright notice in the
On Sat, 14 Apr 2007, William Lee Irwin III wrote:
> The two basic attacks on such large priority spaces are the near future
> vs. far future subdivisions and subdividing the priority space into
> (most often regular) intervals. Subdividing the priority space into
> intervals is the most obvious;
On Fri, 2007-04-13 at 19:18 -0400, David R. Litwin 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
> licence
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
>> A binomial heap would likely serve your purposes better than rbtrees.
[...]
On Sat, Apr 14, 2007 at 03:38:04PM -0700, Davide Libenzi wrote:
> Haven't looked at the scheduler code yet, but for a similar problem I use
> a time ring. The ring has
On 4/13/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
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
On Sat, 2007-04-14 at 17:03 +0200, Adrian Bunk wrote:
> As scheduled, do_setitimer() now returns -EINVAL for invalid timeval.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Saturday 14 April 2007 06:21, 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-sch
Am 03.04.2007 00:50 schrieb Adrian Bunk:
>>/ We also have one bug kwin ran into that got fixed after -rc5:/
>>/ /
>>/ Subject : kwin dies silently/
>>/ References : http://lkml.org/lkml/2007/2/28/112/
>>/ Submitter : Sid Boyce <[EMAIL PROTECTED]>/
>>/ Boris Mogwitz <[EMAIL PROTECTED]>/
>>/ Michael
On 4/15/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
in fact, according to this:
http://lkml.org/lkml/2006/1/13/139
that notice was put in the feature removal file well over a year ago,
during 2.6.15. so that would seem to be more than adequate time for
everyone to prepare for it. but it m
On Sat, 14 Apr 2007, Matthias Andree wrote:
> I arrived at the computer today, to find khubd in D state again, but
> unfortunately, it does not show up in Alt-SysRq-T output. Do kernel
> threads show up there at all? 2.6.18.8-0.1 with SUSE patches on openSUSE
> 10.2.
As far as I know, all tasks i
Hi,
On Thursday 12 April 2007 03:27, Hans de Goede wrote:
> Krzysztof Helt wrote:
>
> >> * Must follow kernel coding style guidelines
> >
> > Is there any tool to check this? If there is one, a basic
> > instruction how to use it would be great.
> >
>
> No tool.
Passing new drivres through sc
I recently noticed that I can no longer read my
images of NeXTstep floppies on certain machines.
All are running an up to date etch distribution
but the difference between where I can read or not
read seems to be the linux version. On a 2.6.18
machine:
# mount -t ufs -o ro,ufstype=nextstep,loop n
I wrote:
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
I meant "the second byte is NOT 0x03", of course.
Paul.
-
To unsubscribe fr
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since
On Fri, Apr 13, 2007 at 05:49:39PM +0400, Anton Vorontsov wrote:
> I'll convert mXh to uXh a bit later, if there will no further objections
> against uXh. Also I'd like to hear if there any objections on
> mA/mV -> uA/uV conversion. I think we'd better keep all units at the
> same order/precision.
The device has commands to start/stop the ADSL function, so this adds
a sysfs attribute to allow it to be started/stopped/restarted. It also
stops polling the device for status when the ADSL function is disabled.
There are no problems with sending multiple start or stop commands,
even with a f
On Sun, 15 Apr 2007, Rene Herman wrote:
"v2.6.20.7" seems to be the only tag from the stable branches that's present
in this tree?
[EMAIL PROTECTED]:[...]$ git tag -l | grep "v2\.6\.[[:digit:]]\{1,2\}\."
v2.6.20.7
Obviously I don't know how Chris created his conglomerated repo, but I
just
Detect usb device shutdown and ignore failed urbs.
This happens when the driver is unloaded or the device is unplugged.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Cc: Duncan Sands <[EMAIL PROTECTED]>
---
I'm not sure what other urb statuses should be ignored,
and the warning message doesn't
(i'm betting that the mail server i use back in canada is going to tag
this yet again with "{Spam?}" since i'm in california at the moment
and i'll just bet it's freaking out seeing stuff coming from a totally
unknown IP address. i've already sent an email to the admins about
this. sorry.)
On S
On 04/15/2007 01:38 AM, Robert P. J. Day wrote:
Why are all your messages getting a "{Spam?}" subject prefix?
i have no idea, that's a recent development. is that happening with
anyone else?
Not that I've seen. Your last message/thread were the others:
http://lkml.org/lkml/2007/4/14/89
Re
On 4/15/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
Remove the obsolete code for the traffic shaper.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Apart from the merits of removing this which I can't comment on, I
thought the usual procedure was to place a removal in
Documentation/f
On Sun, 15 Apr 2007, Rene Herman wrote:
> On 04/15/2007 01:30 AM, Robert P. J. Day wrote:
>
> > Remove the obsolete code for the traffic shaper.
>
> Why are all your messages getting a "{Spam?}" subject prefix?
i have no idea, that's a recent development. is that happening with
anyone else?
rda
On 04/15/2007 01:30 AM, Robert P. J. Day wrote:
Remove the obsolete code for the traffic shaper.
Why are all your messages getting a "{Spam?}" subject prefix?
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
On Mon, 2007-04-02 at 17:41 +1000, CaT wrote:
> On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote:
> > On Mon, 2 Apr 2007 11:43:19 +1000 CaT <[EMAIL PROTECTED]> wrote:
> >
> > > I take minute by minute snapshots of network traffic by sampling
> > > /proc/net/dev and most of the time ev
Remove the obsolete code for the traffic shaper.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
nothing seems to be using this, it's labelled "OBSOLETE" in the
Kconfig file, and there is not a single test for CONFIG_SHAPER
anywhere in the tree. time to die.
Documentation/networking
On Sat, 14 Apr 2007, Davide Libenzi wrote:
> Haven't looked at the scheduler code yet, but for a similar problem I use
> a time ring. The ring has Ns (2 power is better) slots (where tasks are
> queued - in my case they were som sort of timers), and it has a current
> base index (Ib), a current
It looks like nfs_setattr() and nfs_rename() also need to test whether the
target is a regular file before calling nfs_wb_all()...
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/dir.c |3 ++-
fs/nfs/inode.c |6 --
2 files changed, 6 insertions(+), 3 deletions(-)
dif
On 04/14/2007 10:54 AM, Rene Herman wrote:
On 04/14/2007 10:34 AM, Chris Wright wrote:
I've already put a tree like this up on kernel.org. The master branch
is Linus' tree, and there's branches for each of the stable releases
called linux-2.6.[12-20].y (I didn't add 2.6.11.y).
http://git.ker
If the writebacks are cancelled via nfs_cancel_dirty_list, or due to the
memory allocation failing in nfs_flush_one/nfs_flush_multi, then we must
ensure that the PG_writeback flag is cleared.
Also ensure that we actually own the PG_writeback flag whenever we
schedule a new writeback by making nfs_
Do not flag an error if the COMMIT call fails and we decide to resend the
writes. Let the resend flag the error if it fails.
If a write has failed, then nfs_direct_write_result should not attempt to
send a commit. It should just exit asap and return the error to the user.
Signed-off-by: Trond Myk
Hi,
On Saturday, 14 April 2007 00:35, Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 00:10, Pavel Machek wrote:
[--snip--]
> > > 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. F
On Fri, 13 Apr 2007, William Lee Irwin III wrote:
> On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar 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
On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
Jiri Slaby wrote:
: ioctl(fd, TIOCMIWAIT, TIOCM_CD);
[...]
Hmm, I have tried to run this, and got a machine lockup, and after
a minute or so the following has been printed to the console:
Hmm, the driver got shot full of holes
Jeremy Fitzhardinge wrote:
-
+LOW_PAGES = 1<<(32-PAGE_SHIFT_asm)
+
Again, for debugging... it would be interesting to replace this with:
LOW_PAGES = (0x1-__PAGE_OFFSET) >> PAGE_SHIFT_asm
... to smoke out further problems; this will take the strict definition
of "lowmem" (modulo the p
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Die
Hello community.
I use 2.6.17 gentoo.
Take my please reference to documentation, that discribe __WALL, __WNOTHREAD
and __WALL flags for do_wait syscall.
Can be CLONE_THREAD flag (in do_fork syscall) effect to do_wait syscall with
__WNOTHREAD (or __WALL) flag?
Best regards,
yantux.
-
To unsubs
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > > Tobias Diedrich wrote:
> > > > > > > ed746e3
x86_64:
arch/x86_64/kernel/../../i386/kernel/alternative.c: In function
'alternative_instructions':
arch/x86_64/kernel/../../i386/kernel/alternative.c:374: error:
'__parainstructions' undeclared (first use in this function)
arch/x86_64/kernel/../../i386/kernel/alternative.c:374: error: (Each und
Don't implement native_kmap_atomic_pte for !HIGHPTE case; it is never needed,
never called, and leaving it in is just plain confusing. Making it isolated
to the config where it is used may help find bugs.
From: Zachary Amsden <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
A
From: Zachary Amsden <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
---
arch/i386/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -220,7
Convert VMI timer to use clock events, making it properly able to use the NO_HZ
infrastructure. On UP systems, with no local APIC, we just continue to route
these events through the PIT. On systems with a local APIC, or SMP, we provide
a single source interrupt chip which creates the local timer
Remove #defines, add enum for PARAVIRT_LAZY_FLUSH.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-i386/paravirt.h |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
===
--- a/include/asm-i386/par
inflate_fixed and huft_build together use around 2.7k of stack. When
using 4k stacks, I saw stack overflows from interrupts arriving while
unpacking the root initrd:
do_IRQ: stack overflow: 384
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] do_IRQ+0x6d/0xd9
The other symbols used to delineate the alt-instructions sections have the
form __foo/__foo_end. Rename parainstructions to match.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL P
Implement vmi_kmap_atomic_pte in terms of the backend set_linear_mapping
operation. The conversion is rather straighforward; call kmap_atomic
and then inform the hypervisor of the page mapping.
The _flush_tlb damage is due to macros being pulled in from highmem.h.
From: Zachary Amsden <[EMAIL PR
From: Zachary Amsden <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
CC: Trivial <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/earlyquirk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/arc
I got so sick of seing the check_region warnings from BusLogic.c I actually
fixed it properly. Never use check region, reserve it before the probe
with request region instead and check the error result; free region if
setup fails. Should be functionally identical to the original except for
fixing
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/bugs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/arch/i386/kernel/cpu/bugs.c
+++ b/arch/i386/kernel/cpu/bugs.c
@@ -177,7 +177,7
Copying of the pgd range must happen under the pgd_lock. This got broken by
the paravirt changes in the -mm tree. Badness can result if you copy the pgd
before being added to the list when splitting or rejoining large pages.
From: Zachary Amsden <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden
No, just no. You do not use goto to skip a code block. You do not
return an obvious variable from a singly-inlined function and give
the function a return value. You don't put unexplained comments
about kmalloc in code which doesn't do dynamic allocation. And
you don't leave stray warnings arou
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 rounded up to 4Mbytes, and so this
typically ends up mapping 8Mbytes of memory.
When booting, pagetable_init() needs to create mapp
From: Zachary Amsden <[EMAIL PROTECTED]>
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
---
arch/i386/kernel/sysenter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/arch/i386/kernel/sysenter.c
+++ b/arch/i38
Currently x86 (similar to x84-64) has a special per-cpu structure
called "i386_pda" which can be easily and efficiently referenced via
the %fs register. An ELF section is more flexible than a structure,
allowing any piece of code to use this area. Indeed, such a section
already exists: the per-cp
i386 bugs.c shouldn't refer to identify_boot_cpu yet, since it doesn't
get introduced until the identify_cpu patch.
Remove spurious comments, headers and keywords from x86-64 bugs.[ch].
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/bugs.c |2 +-
arch/x86_64
kunmap_atomic should flush any pending lazy mmu updates, mainly to be
consistent with kmap_atomic, and to preserve its normal behaviour.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/mm/highmem.c |1 +
1 file changed, 1 insertion(+)
===
Fixes two problems with the GDT when compiling for uniprocessor:
- There's no percpu segment, so trying to load its selector into %fs fails.
Use a null selector instead.
- The real gdt needs to be loaded at some point. Do it in cpu_init().
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Sign
Xen wants a dedicated page for the GDT. I believe VMI likes it too.
lguest, KVM and native don't care.
Simple transformation to page-aligned "struct gdt_page".
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/common.c |
Make sure allocation is page-aligned.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
init/main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
===
--- a/init/main.c
+++ b/init/main.c
@@ -370,7 +370,7 @@ stati
Rather than using a single constant PERCPU_ENOUGH_ROOM, compute it as
the sum of kernel_percpu + PERCPU_MODULE_RESERVE. This is now common
to all architectures; if an architecture wants to set
PERCPU_ENOUGH_ROOM to something special, then it may do so (ia64 is
the only one which does).
Signed-off
The tsc-based get_scheduled_cycles interface is not a good match for
Xen's runstate accounting, which reports everything in nanoseconds.
This patch replaces this interface with a sched_clock interface, which
matches both Xen and VMI's requirements.
In order to do this, we:
1. replace get_sched
Define per_cpu_offset in asm-i386/percpu.h when SMP defined, like
asm-generic/percpu.h does for UP.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/percpu.h |2 ++
1 file changed, 2 insertion
In shadow mode hypervisors, ptep_get_and_clear achieves the desired
purpose of keeping the shadows in sync by issuing a native_get_and_clear,
followed by a call to pte_update, which indicates the PTE has been
modified.
Direct mode hypervisors (Xen) have no need for this anyway, and will trap
the u
This patch does a few small cleanups:
- use PER_CPU_NAME to generate the names of per-cpu variables
- use lea to add the per_cpu offset in PER_CPU(), because it doesn't
affect condition flags
- add PER_CPU_VAR which allows direct access to pre-cpu variables
with the %fs: prefix on SMP.
Si
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmi.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
===
--- a/arch/i386/kernel/vmi.c
+++ b/arch/
Hi Andi,
This is a set of updates for the firstfloor patch queue.
Quick rundown:
revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch
separate-module-percpu-space.patch
Update the module percpu accounting patch
fix-ff-allow-percpu-variables-to-be-page-
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-i386/percpu.h | 10 --
1 file changed, 10 deletions(-)
===
--- a/include/asm-i386/percpu.h
+++ b/include/asm-i386/percpu.h
@@ -4,16 +4,6 @@
#ifndef __
On Sat, Apr 14, 2007 at 10:04:23AM -0400, Mike Snitzer wrote:
> ZFS does have some powerful features but much of it depends on their
> broken layering of volume management. Embedding the equivalent of LVM
> into a filesystem _feels_ quite wrong.
They have a clustering concept in their volume mana
Andi Kleen wrote:
> Fixed now. The latest sched-clock was leaking preempt counts during
> cpu frequency changes.
>
No, that didn't help. I think its cpufreq:
Apr 14 13:58:29 localhost kernel: BUG: scheduling while atomic:
swapper/0x0002/1
Apr 14 13:58:29 localhost kernel: 2 locks held by
On 4/14/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
Francis Moreau <[EMAIL PROTECTED]> wrote:
>
> hmm yes indeed it should do the job, but I don't see how you do that.
> For example, let say I want to use "aes-foo" with eCryptfs. I can give
> a higher priority to "aes-foo" than "aes" one. When eCry
FYI, this bug occurs also in 2.6.20.7 vanilla...
Honestly I don't know if I'm doing nasty things there, but I tested the
following patch and it seems to fix the problem (at least for my case).
It explicitly invalidates all the dentries in the reiserfs "private" dir
and releases all the valid xatt
On Apr 14 2007 10:04, Mike Snitzer wrote:
>
> ZFS does have some powerful features but much of it depends on their
> broken layering of volume management. Embedding the equivalent of LVM
> into a filesystem _feels_ quite wrong.
>
>[...]
>
> Unfortunately in order for Linux to incorporate such a f
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote:
> On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote:
> >...
> > Also, would that be feasible for you to use 'shutdown' as a workaround in
> > case
> > the source of the problem is difficult to find and/or fix?
>
> One person rep
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote:
>...
> Also, would that be feasible for you to use 'shutdown' as a workaround in case
> the source of the problem is difficult to find and/or fix?
One person reporting a regression against a -rc kernel can mean
houndreds or thousan
Jiri Slaby wrote:
: On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
: >Jiri Slaby wrote:
: >: On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
: >: >~BUG: spinlock lockup on CPU#0, sshd/1671, 80557780
: >: [...]
: >: >the write(1, "/file/name/...", ...) call returned -EIO
On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
Jiri Slaby wrote:
: On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
: >~BUG: spinlock lockup on CPU#0, sshd/1671, 80557780
: [...]
: >the write(1, "/file/name/...", ...) call returned -EIO.
:
: Just a question: both with
Jiri Slaby wrote:
: On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
: >~BUG: spinlock lockup on CPU#0, sshd/1671, 80557780
: [...]
: >the write(1, "/file/name/...", ...) call returned -EIO.
:
: Just a question: both with mxser_new, right?
No. One side has a multiport C16
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > Tobias Diedrich wrote:
> > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is
On Sat, Apr 14, 2007 at 12:48:55PM -0700, William Lee Irwin III wrote:
> On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
> > Forking becomes very slow above a load of 100 it seems. Sometimes,
> > the shell takes 2 or 3 seconds to return to prompt after I run
> > "scheddos &"
> > Thos
On 4/14/07, Jan Yenya Kasprzak <[EMAIL PROTECTED]> wrote:
~BUG: spinlock lockup on CPU#0, sshd/1671, 80557780
[...]
the write(1, "/file/name/...", ...) call returned -EIO.
Just a question: both with mxser_new, right?
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
fa
On Sat, Apr 14, 2007 at 02:02:20PM +0200, Ingo Molnar wrote:
> cool. ringtest.c is intended to be used the following way: start it, it
> will generate a 99% busy system (but it is using a ring of 100 tasks,
> where each tasks runs for 100 msecs then sleeps for 1 msec, so every
> task gets a turn
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > Tobias Diedrich wrote:
> > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > commit ed746e3b18f4df18afa3763155972c583
Jiri Slaby wrote:
: >I have another problem with the driver - it probably sometimes
: >drops DCD signal on the serial line or something like that:
: >when the traffic on the serial console is heavy, it sometimes disconnects
: >me from the remote shell, and cu(1) displays the login prompt fr
On Sat, Apr 14, 2007 at 10:36:25AM +0200, Willy Tarreau wrote:
> Forking becomes very slow above a load of 100 it seems. Sometimes,
> the shell takes 2 or 3 seconds to return to prompt after I run
> "scheddos &"
> Those are very promising results, I nearly observe the same responsiveness
> as I had
On 04/14, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 04/13, Eric W. Biederman wrote:
> >>
> >> +static inline int __kthread_should_stop(struct task_struct *tsk)
> >> +{
> >> + return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
> >> +}
> >
> > Am I blind? Wher
Francis Moreau <[EMAIL PROTECTED]> wrote:
>
> hmm yes indeed it should do the job, but I don't see how you do that.
> For example, let say I want to use "aes-foo" with eCryptfs. I can give
> a higher priority to "aes-foo" than "aes" one. When eCryptfs asks for
> a aes cipher it will pass "aes" nam
On Sat, 14 Apr 2007, Chris Wright wrote:
* Brian Gernhardt ([EMAIL PROTECTED]) wrote:
On Apr 14, 2007, at 4:34 AM, Chris Wright wrote:
I've already put a tree like this up on kernel.org. The master branch
is Linus' tree, and there's branches for each of the stable releases
called linux-2.6.[1
On Sat, Apr 14, 2007 at 12:40:15PM -0600, Eric W. Biederman wrote:
> Willy Tarreau <[EMAIL PROTECTED]> writes:
>
> > On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
> >>
> >> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >>
> >> > > Thinking about it, I don't know if there are ca
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/13, Eric W. Biederman wrote:
>>
>> +static inline int __kthread_should_stop(struct task_struct *tsk)
>> +{
>> +return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
>> +}
>
> Am I blind? Where does copy_process/dup_task_struct clears unwanted
> f
On 04/14, Eric W. Biederman wrote:
>
> This is where I was going beyond what you were doing. I needed a flag to say
> that this a kthread that is stopping to test in recalc_sigpending. To be
> certain
> of terminating interruptible sleeps. I could not get at your struct kthread
> in that case.
On Sat, Apr 14, 2007 at 01:18:09AM +0200, Ingo Molnar wrote:
> very much so! Both Con and Mike has contributed regularly to upstream
> sched.c:
The problem here is tha Con can get demotivated (and rather upset) when an
idea gets proposed, like SchedPlug, only to have people be hostile to it
and t
Please don't do this. Using the same name for a branch as for a tag is
madness. Call it "v2.6.20-stable" or anything else, but don't re-use the
same naming as for tags.
Yes I have done this before, and it took me awhile to realize what was
going on. It caused me some grief, and a few hours of
Willy Tarreau <[EMAIL PROTECTED]> writes:
> On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
>>
>> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> > > Thinking about it, I don't know if there are calls to schedule()
>> > > while switching from tty1 to tty2. Alt-F2 had no effect
On 04/13, Eric W. Biederman wrote:
>
> +static inline int __kthread_should_stop(struct task_struct *tsk)
> +{
> + return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
> +}
Am I blind? Where does copy_process/dup_task_struct clears unwanted
flags in thread_info->flags ?
> +int kthread_stop(stru
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/13, Eric W. Biederman wrote:
>>
>> 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
> kth
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > Tobias Diedrich wrote:
> > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > Author: Rafael J. W
On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
>
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > > Thinking about it, I don't know if there are calls to schedule()
> > > while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
> > > "chvt 2" simply blocked. It w
On 04/13, Eric W. Biederman wrote:
>
> 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
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > Thinking about it, I don't know if there are calls to schedule()
> > while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
> > "chvt 2" simply blocked. It would have been possible that a
> > schedule() call somewhere got starved
1 - 100 of 196 matches
Mail list logo
