* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 19:33 UTC (permalink / raw)
To: balrogg, qemu-devel
In-Reply-To: <fb249edb0604081221w1228728hc7c885892d9da7de@mail.gmail.com>
The Win4Lin Pro version is not a driver, but rather a high-priority
Windows userspace thread. We try to avoid drivers as much as possible
because they are a serious obstacle to supporting new Windows versions
and service packs as they come out. I can't comment on VMware's
approach to be honest.
I will say that using a device that has readily and/or publicly
available drivers is probably ideal, such as a Wacom tablet. We are
trying to move to more of a device model on Win4Lin Pro for performance
reasons, which is why I am interested in this approach. But letting
Microsoft maintain the guest driver, if it's built into Windows, is the
best solution. It also guarantees the broadest possible guest support
in general - whether it be Linux, Mac OS X, etc.
If anyone has a link to Anthony Liguori's driver, I'd be glad to look
into fixing whatever may be wrong with it and posting the patches.
Thanks,
Leo Reiter
andrzej zaborowski wrote:
> I thought Anthony Liguori had already written a Wacom tablet emulator
> for QEMU and that worked fine except it supports only one button. I
> don't remember if this support was complete and I don't have a link to
> the patch.
>
> With this you don't need to disable mouse acceleration in the guest OS
> because it makes no sense to accelerate a tablet.
>
> On the other hand writing a guest-side driver for QEMU would leave
> room for further improvements like hiding/showing or
> grabbing/releasing the mouse at specific moments. Or, possibly reusing
> tools from Win4Lin or VMtools from VMware.
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Johannes Schindelin @ 2006-04-08 19:40 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408193048.GB17347@jbrown.mylinuxbox.org>
Hi,
On Sat, 8 Apr 2006, Jim C. Brown wrote:
> On Sat, Apr 08, 2006 at 09:12:18PM +0200, Johannes Schindelin wrote:
> > > Anthony Ligouri has written a patch for wacom support.
> > >
> > > However, when I combine this with the -no-sdl-grab patch I still see syncing
> > > issues.
> >
> > Where can I get it?
>
> http://www.cs.utexas.edu/users/aliguori/qemu-wacom-2.tgz
Thanks! I will play around a little.
Ciao,
Dscho
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Guennadi Liakhovetski @ 2006-04-08 19:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: James Courtier-Dutton, linux-kernel
In-Reply-To: <p73odzc9ocx.fsf@bragg.suse.de>
On Sat, 8 Apr 2006, Andi Kleen wrote:
> James Courtier-Dutton <James@superbug.co.uk> writes:
> >
> > Now, the question I have is, if I write values to RAM, do any of those
> > values survive a reset?
>
> They don't generally.
>
> Some people used to write the oopses into video memory, but that
> is not portable.
Some even write them to mtd (NOR flash), but that is even less portable:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Funny repack behaviour
From: Nicolas Pitre @ 2006-04-08 19:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604081233170.3283@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, 8 Apr 2006, Johannes Schindelin wrote:
> Hi,
>
> I just accidentally reran "git-repack -a -d" on a repository, where I just
> had run it. And I noticed a funny thing: Of about 4000 objects, it reused
> all but 8. So I reran it, and it reused all but 2. I ran it once again,
> and it reused all.
>
> The really funny thing is: it created the same pack every time!
Probably not. Subsequent packs were most probably even smaller !
> It is not critical, evidently, but I'd like to know what is causing this
> rather undeterministic behaviour. (Before you ask: no, I did not make a
> backup before running the tests, so I unfortunately cannot reproduce it).
To reproduce, or rather to reset the pack state, just use
"git-repack -a -f -d" then "git-repack -a -d" multiple times again.
For example, on the current git archive:
$ git-repack -a -f -d
[...]
Total 16548, written 16548 (delta 11007), reused 5390 (delta 0)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
pack size = 6032083 bytes.
$ git-repack -a -d
[...]
Total 16548, written 16548 (delta 11030), reused 16525 (delta 11007)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
pack size = 5976610 bytes
$ git-repack -a -d
[...]
Total 16548, written 16548 (delta 11030), reused 16548 (delta 11030)
Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created.
Pack size = 5976610 bytes
So in this case it took 2 itterations before converging on a smaller
pack by 55473 bytes.
I thought the reuse logic might sacrifice a bit on compression given the
speed boost, but I don't get why it is the opposite in practice and that
-f doesn't produce the smallest pack up front.
Nicolas
^ permalink raw reply
* Re: [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Stefan Richter @ 2006-04-08 19:49 UTC (permalink / raw)
To: Dan Dennedy; +Cc: linux1394-devel, Adrian Bunk, scjody, linux-kernel
In-Reply-To: <200604081218.24544.dan@dennedy.org>
Dan Dennedy wrote:
> Kino still uses the legacy raw1394 iso interface for capture by default;
> however, it can also still use dv1394. I will accellerate the adoption of the
> new raw1394 interface since I have already done this for dvgrab 2.0.
> Cinelerra supports libiec61883 now.
>
> Unfortunately, gstreamer still uses legacy raw1394 iso interface, but I can
> nag someone at Fluendo. I think another high profile app that might be
> affected is GnomeMeeting/Ekiga, but I have not kept close track of it.
>
> Also, I have not released a version of libraw1394 that contains the
> deprecation warnings, but I can do so this weekend. And then another release
> when the removed kernel interfaces are released that removes the functions.
Then I suggest we adjust the date in
Documentation/feature-removal-schedule.txt (increment by 1 year?) and
also list kino and gstreamer as affected application programs there.
It appears from grep'ing through the sources of Ekiga 2.0.1 that it does
not access (lib)raw1394 by itself.
--
Stefan Richter
-=====-=-==- -=-- -=---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Stefan Richter @ 2006-04-08 19:53 UTC (permalink / raw)
To: Dan Dennedy; +Cc: linux1394-devel, Adrian Bunk, scjody, linux-kernel
In-Reply-To: <443813C4.9090000@s5r6.in-berlin.de>
> Dan Dennedy wrote:
>> Also, I have not released a version of libraw1394 that contains the
>> deprecation warnings, but I can do so this weekend. And then another
>> release when the removed kernel interfaces are released that removes
>> the functions.
We should have added such warnings already to the kernel at the moment
when the two ioctls went into feature-removal-schedule.txt.
--
Stefan Richter
-=====-=-==- -=-- -=---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/3] [kernel patch] fixed duration connection
From: Patrick McHardy @ 2006-04-08 19:56 UTC (permalink / raw)
To: Eric Leblond; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <4436E03E.9030402@inl.fr>
Eric Leblond wrote:
> Hi,
>
> Here's the patch against Linus git tree.
I don't have any principle objections against merging this (if
there are no objections from others), a couple of comments
on the patch though.
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) ||
defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+#endif
Probably not worth adding a config option for this.
+
};
@@ -85,6 +85,7 @@ struct ip_conntrack
/* Timer function; drops refcnt when it goes off. */
struct timer_list timeout;
+
Please remove this.
#ifdef CONFIG_IP_NF_CT_ACCT
/* Accounting Information (same cache line as other written members) */
struct ip_conntrack_counter counters[IP_CT_DIR_MAX];
@@ -292,6 +293,13 @@ static inline int is_dying(struct ip_con
return test_bit(IPS_DYING_BIT, &ct->status);
}
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) ||
defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+static inline int is_fixedtimeout(struct ip_conntrack *ct)
+{
+ return test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status);
+}
+#endif
I guess without a seperate config option we don't need this function
anymore.
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c
b/net/ipv4/netfilter/ip_conntrack_core.c
index ceaabc1..44fa788 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1130,18 +1130,27 @@ void __ip_ct_refresh_acct(struct ip_conn
write_lock_bh(&ip_conntrack_lock);
- /* If not in hash table, timer will not be active yet */
- if (!is_confirmed(ct)) {
- ct->timeout.expires = extra_jiffies;
- event = IPCT_REFRESH;
- } else {
- /* Need del_timer for race avoidance (may already be dying). */
- if (del_timer(&ct->timeout)) {
- ct->timeout.expires = jiffies + extra_jiffies;
- add_timer(&ct->timeout);
- event = IPCT_REFRESH;
- }
- }
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) ||
defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+ /* only update if this is not a fixed timeout */
+ if (! is_fixedtimeout(ct)){
+#endif
+ /* If not in hash table, timer will not be active yet */
+ if (!is_confirmed(ct)) {
+ ct->timeout.expires = extra_jiffies;
+ event = IPCT_REFRESH;
+ } else {
+ /* Need del_timer for race avoidance (may already be dying). */
+ if (del_timer(&ct->timeout)) {
+ ct->timeout.expires = jiffies + extra_jiffies;
+ add_timer(&ct->timeout);
+ event = IPCT_REFRESH;
+ }
+ }
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT)
+ } else {
+ DEBUGP("FIXED TIMEOUT: Not updating\n");
+ }
+#endif
Please just do a simple
if (!test_bit(...))
return;
at the beginning.
^ permalink raw reply related
* Re: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection
From: Patrick McHardy @ 2006-04-08 19:58 UTC (permalink / raw)
To: Eric Leblond; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <4436E0B6.9040602@inl.fr>
Eric Leblond wrote:
> Hi,
>
> This patch add support for the IPS_FIXED_TIMEOUT state.
>
> BR,
> --
> Regit
>
>
> ------------------------------------------------------------------------
>
> Index: include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h
> ===================================================================
> --- include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (révision 6576)
> +++ include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (copie de travail)
> @@ -29,6 +29,7 @@
> CTA_HELP,
> CTA_NAT,
> CTA_TIMEOUT,
> + CTA_FIXED_TIMEOUT,
> CTA_MARK,
> CTA_COUNTERS_ORIG,
> CTA_COUNTERS_REPLY,
I didn't see the patch adding support for this in the kernel. Since
there is no seperate fixed timeout anymore, this also looks obsolete.
The way I understood the kernel patch, you would just do two netlink
operations:
- set flag FIXED_TIMEOUT
- change timeout using CTA_TIMEOUT
Am I missing something?
^ permalink raw reply
* strange behavior when pulling updates / get uptodate with git.git
From: Nicolas Vilz 'niv' @ 2006-04-08 19:57 UTC (permalink / raw)
To: git
Hello guys,
I experience a loss of tags- and branch-updates, when I try to update my
repository.
I normaly do following
git checkout master
git pull origin
my .git/remotes/origin-file looks like this:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/todo:refs/heads/todo
Pull: refs/heads/maint:refs/heads/maint
Pull: refs/heads/pu:refs/heads/pu
Pull: refs/heads/man:refs/heads/man
Pull: refs/heads/next:refs/heads/next
Pull: refs/heads/html:refs/heads/html
so i suppose, if i try to pull origin, and i am in master, i should be
able to pull these remote heads each in the correct local head...
But I obviously don't.
after deleting the actual git-repository directory and recloning with
git clone <url>
I have obviously more tags than git was trying to merge before at git
pull origin..
I use git version 1.3.0.rc1.g4c0f (located in the next-tree).
Any hints how this could be better on my system?
Sincerly
Nicolas
^ permalink raw reply
* [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-08 20:02 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 20:02:06
Modified files:
. : exec.c
Log message:
Initialize physical memory space to IO_MEM_UNASSIGNED.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.76&tr2=1.77&r1=text&r2=text
^ permalink raw reply
* Re: [PATCH] Script for automated historical Git tree grafting
From: Nicholas Miell @ 2006-04-08 20:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andrew Morton, torvalds, linux-kernel, git
In-Reply-To: <20060408030936.GN27631@pasky.or.cz>
On Sat, 2006-04-08 at 05:09 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 07, 2006 at 02:52:46AM CEST, I got a letter
> where Andrew Morton <akpm@osdl.org> said that...
> > Petr Baudis <pasky@suse.cz> wrote:
> > >
> > > This script enables Git users to easily graft the historical Git tree
> > > (Bitkeeper history import) to the current history.
> >
> > What impact will that have on the (already rather poor) performance of
> > git-whatchanged, gitk, etc?
>
> Negative. ;-)
>
> I didn't try gitk myself, but according to Nick Riviera it eats 1.6G...
> Otherwise, assuming that you have at least git-1.2.5, git-whatchanged on
> the whole tree should be roughly equally fast as it was before grafting,
> but git-whatchanged on individual paths is _significantly_ slower.
>
> That said, 1.3.0rc2 should already have Linus' optimization which should
> fix or at least mitigate the performance hit on narrowed-down
> git-whatchanged.
Actually, it ate more than 1.6G -- that was just the resident size, and
it likes to allocate more memory in between you closing the window and
it finally exiting (or, you killing it before it OOMs the box, whichever
comes first).
qgit has absolutely no problem with the grafted full history, though,
and those previously mentioned rev-list changes by Linus should fix
git-whatchanged.
Unfortunately, this does nothing to fix the disturbing lack of useless
Simpsons trivia knowledge in the git community. Keith Packard made the
same mistake last week.
--
Nicholas Miell <nmiell@comcast.net>
^ permalink raw reply
* Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-08 20:09 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604022037380.3781@g5.osdl.org>
On Sun, Apr 02, 2006 at 08:47:06PM -0700, you [Linus Torvalds] wrote:
>
> Ok,
> it's two weeks since 2.6.16, and the merge window is closed.
I upgraded from 2.6.15-rc7 to 2.6.17-rc1. rc1 seems nice other than that
iptables stopped working:
failed iptables v1.3.5: can't initialize iptables table filter: iptables
who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables is compiled in the kernel, not a module:
CONFIG_NETFILTER=y
I can even do "modprobe iptable_nat" successfully (iptable_nat is module),
but iptables refuses to work. iptables is of version iptables-1.3.5-1.2.
The kernel config is copied with make oldconfig from 2.6.15-rc7 (which
worked), not much else has changed. I just booted back to 2.6.15-rc7 and
verified it works. Any ideas?
-- v --
v@iki.fi
^ permalink raw reply
* [PATCH rc1-mm 0/3] coredump: rfc
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
I am unsure about this series. It adds some optimizations, but
complicates the code.
So I am asking for yours opinion not only about correctness, but
also about usefulness.
Oleg.
^ permalink raw reply
* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: Sam Ravnborg @ 2006-04-08 20:14 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, hpa, mm-commits
In-Reply-To: <200604080707.k38778VV023208@shell0.pdx.osdl.net>
On Sat, Apr 08, 2006 at 12:05:54AM -0700, akpm@osdl.org wrote:
> diff -puN usr/dash/mkbuiltins~git-klibc-mktemp-fix usr/dash/mkbuiltins
> --- 25/usr/dash/mkbuiltins~git-klibc-mktemp-fix Sat Apr 8 14:51:11 2006
> +++ 25-akpm/usr/dash/mkbuiltins Sat Apr 8 14:51:11 2006
> @@ -37,7 +37,7 @@
>
> tempfile=tempfile
> if ! type tempfile > /dev/null 2>&1; then
> - tempfile=mktemp
> + tempfile="mktemp /tmp/tmp.XXXXXX"
Shouldn't that be:
> + tempfile="$(mktemp /tmp/tmp.XXXXXX)"
Sam
^ permalink raw reply
* [PATCH rc1-mm 1/3] coredump: some code relocations
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
This is a preparation for the next patch. No functional changes.
Basically, this patch moves '->flags & SIGNAL_GROUP_EXIT' check
into zap_threads(), and 'complete(vfork_done)' into coredump_wait
outside of ->mmap_sem protected area.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/fs/exec.c~1_clean 2006-04-07 01:32:02.000000000 +0400
+++ MM/fs/exec.c 2006-04-09 02:33:28.000000000 +0400
@@ -1405,20 +1405,22 @@ static void zap_process(struct task_stru
unlock_task_sighand(start, &flags);
}
-static void zap_threads(struct mm_struct *mm)
+static inline int zap_threads(struct task_struct *tsk, struct mm_struct *mm,
+ int exit_code)
{
struct task_struct *g, *p;
- struct task_struct *tsk = current;
- struct completion *vfork_done = tsk->vfork_done;
+ int err = -EAGAIN;
- /*
- * Make sure nobody is waiting for us to release the VM,
- * otherwise we can deadlock when we wait on each other
- */
- if (vfork_done) {
- tsk->vfork_done = NULL;
- complete(vfork_done);
+ spin_lock_irq(&tsk->sighand->siglock);
+ if (!(tsk->signal->flags & SIGNAL_GROUP_EXIT)) {
+ tsk->signal->flags = SIGNAL_GROUP_EXIT;
+ tsk->signal->group_exit_code = exit_code;
+ tsk->signal->group_stop_count = 0;
+ err = 0;
}
+ spin_unlock_irq(&tsk->sighand->siglock);
+ if (err)
+ return err;
rcu_read_lock();
for_each_process(g) {
@@ -1432,22 +1434,43 @@ static void zap_threads(struct mm_struct
} while ((p = next_thread(p)) != g);
}
rcu_read_unlock();
+
+ return mm->core_waiters;
}
-static void coredump_wait(struct mm_struct *mm)
+static int coredump_wait(int exit_code)
{
- DECLARE_COMPLETION(startup_done);
+ struct task_struct *tsk = current;
+ struct mm_struct *mm = tsk->mm;
+ struct completion startup_done;
+ struct completion *vfork_done;
int core_waiters;
+ init_completion(&mm->core_done);
+ init_completion(&startup_done);
mm->core_startup_done = &startup_done;
- zap_threads(mm);
- core_waiters = mm->core_waiters;
+ core_waiters = zap_threads(tsk, mm, exit_code);
up_write(&mm->mmap_sem);
+ if (unlikely(core_waiters < 0))
+ goto fail;
+
+ /*
+ * Make sure nobody is waiting for us to release the VM,
+ * otherwise we can deadlock when we wait on each other
+ */
+ vfork_done = tsk->vfork_done;
+ if (vfork_done) {
+ tsk->vfork_done = NULL;
+ complete(vfork_done);
+ }
+
if (core_waiters)
wait_for_completion(&startup_done);
+fail:
BUG_ON(mm->core_waiters);
+ return core_waiters;
}
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
@@ -1481,22 +1504,9 @@ int do_coredump(long signr, int exit_cod
}
mm->dumpable = 0;
- retval = -EAGAIN;
- spin_lock_irq(¤t->sighand->siglock);
- if (!(current->signal->flags & SIGNAL_GROUP_EXIT)) {
- current->signal->flags = SIGNAL_GROUP_EXIT;
- current->signal->group_exit_code = exit_code;
- current->signal->group_stop_count = 0;
- retval = 0;
- }
- spin_unlock_irq(¤t->sighand->siglock);
- if (retval) {
- up_write(&mm->mmap_sem);
+ retval = coredump_wait(exit_code);
+ if (retval < 0)
goto fail;
- }
-
- init_completion(&mm->core_done);
- coredump_wait(mm);
/*
* Clear any false indication of pending signals that might
^ permalink raw reply
* [PATCH rc1-mm 2/3] coredump: shutdown current process first
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
This patch optimize zap_threads() for the case when there are
no ->mm users except the current's thread group. In that case
we can avoid 'for_each_process()' loop.
It also adds a useful invariant: SIGNAL_GROUP_EXIT (if checked
under ->siglock) always implies that all threads (except may be
current) have pending SIGKILL.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/fs/exec.c~2_optmz 2006-04-09 02:33:28.000000000 +0400
+++ MM/fs/exec.c 2006-04-09 03:06:43.000000000 +0400
@@ -1383,13 +1383,7 @@ static void format_corename(char *corena
static void zap_process(struct task_struct *start)
{
struct task_struct *t;
- unsigned long flags;
- /*
- * start->sighand can't disappear, but may be
- * changed by de_thread()
- */
- lock_task_sighand(start, &flags);
start->signal->flags = SIGNAL_GROUP_EXIT;
start->signal->group_stop_count = 0;
@@ -1401,40 +1395,51 @@ static void zap_process(struct task_stru
signal_wake_up(t, 1);
}
} while ((t = next_thread(t)) != start);
-
- unlock_task_sighand(start, &flags);
}
static inline int zap_threads(struct task_struct *tsk, struct mm_struct *mm,
int exit_code)
{
struct task_struct *g, *p;
+ unsigned long flags;
int err = -EAGAIN;
spin_lock_irq(&tsk->sighand->siglock);
if (!(tsk->signal->flags & SIGNAL_GROUP_EXIT)) {
- tsk->signal->flags = SIGNAL_GROUP_EXIT;
tsk->signal->group_exit_code = exit_code;
- tsk->signal->group_stop_count = 0;
+ zap_process(tsk);
err = 0;
}
spin_unlock_irq(&tsk->sighand->siglock);
if (err)
return err;
+ if (atomic_read(&mm->mm_users) == mm->core_waiters + 1)
+ goto done;
+
rcu_read_lock();
for_each_process(g) {
+ if (g == tsk->group_leader)
+ continue;
+
p = g;
do {
if (p->mm) {
- if (p->mm == mm)
+ if (p->mm == mm) {
+ /*
+ * p->sighand can't disappear, but
+ * may be changed by de_thread()
+ */
+ lock_task_sighand(p, &flags);
zap_process(p);
+ unlock_task_sighand(p, &flags);
+ }
break;
}
} while ((p = next_thread(p)) != g);
}
rcu_read_unlock();
-
+done:
return mm->core_waiters;
}
^ permalink raw reply
* [PATCH rc1-mm 3/3] coredump: copy_process: don't check SIGNAL_GROUP_EXIT
From: Oleg Nesterov @ 2006-04-09 0:11 UTC (permalink / raw)
To: linux-kernel
Cc: Eric W. Biederman, Ingo Molnar, Paul E. McKenney, Roland McGrath,
Andrew Morton, Lee Revell
After the previous patch SIGNAL_GROUP_EXIT implies a pending SIGKILL,
we can remove this check from copy_process() because we already checked
!signal_pending().
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
--- MM/kernel/fork.c~3_fork 2006-03-23 22:59:33.000000000 +0300
+++ MM/kernel/fork.c 2006-04-09 03:17:12.000000000 +0400
@@ -1157,18 +1157,6 @@ static task_t *copy_process(unsigned lon
}
if (clone_flags & CLONE_THREAD) {
- /*
- * Important: if an exit-all has been started then
- * do not create this new thread - the whole thread
- * group is supposed to exit anyway.
- */
- if (current->signal->flags & SIGNAL_GROUP_EXIT) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
- retval = -EAGAIN;
- goto bad_fork_cleanup_namespace;
- }
-
p->group_leader = current->group_leader;
list_add_tail_rcu(&p->thread_group, &p->group_leader->thread_group);
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Brad Campbell @ 2006-04-08 20:19 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <443802FB.9060700@win4lin.com>
Leonardo E. Reiter wrote:
> The mouse sync solution we have in Win4Lin Pro is okay, but it's a bit
> slow and I'd like to do something much cleaner. Of course if I do the
> wacom tablet implementation, it will be open source and part of QEMU
> itself.
>
This link might or might not be intersting
http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en
Apparently USB HID supports absolute input devices natively. Given we have a HID mouse driver of
sorts in qemu I wonder if that is another avenue perhaps ?
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
^ permalink raw reply
* Re: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection
From: Eric Leblond @ 2006-04-08 20:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <44381602.5090105@trash.net>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Patrick McHardy wrote:
> Eric Leblond wrote:
>
>>Hi,
>>
>>This patch add support for the IPS_FIXED_TIMEOUT state.
> I didn't see the patch adding support for this in the kernel. Since
> there is no seperate fixed timeout anymore, this also looks obsolete.
> The way I understood the kernel patch, you would just do two netlink
> operations:
>
> - set flag FIXED_TIMEOUT
> - change timeout using CTA_TIMEOUT
>
> Am I missing something?
Clearly not. I was a little bit too tired yesterday and I've done a "svn
diff" in the bad directory. Please ignore previous patch and consider
this far smaller one.
Best regards,
--
Eric Leblond
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libnetfilter_conntrack_fixed_timeout-flag.patch --]
[-- Type: text/x-patch; name="libnetfilter_conntrack_fixed_timeout-flag.patch", Size: 574 bytes --]
Index: include/libnetfilter_conntrack/libnetfilter_conntrack.h
===================================================================
--- include/libnetfilter_conntrack/libnetfilter_conntrack.h (révision 6578)
+++ include/libnetfilter_conntrack/libnetfilter_conntrack.h (copie de travail)
@@ -191,6 +191,11 @@
/* Connection is dying (removed from lists), can not be unset. */
IPS_DYING_BIT = 9,
IPS_DYING = (1 << IPS_DYING_BIT),
+
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+
};
enum {
^ permalink raw reply
* [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:24 UTC (permalink / raw)
To: git
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
test-delta.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3e2552fff69fb01249fed53380e24e11754afcdf
diff --git a/test-delta.c b/test-delta.c
index 1be8ee0..94b47f0 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -27,7 +27,7 @@ int main(int argc, char *argv[])
void *from_buf, *data_buf, *out_buf;
unsigned long from_size, data_size, out_size;
- if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
+ if (argc != 5 || (strcmp(argv[1], "-d") || strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage);
return 1;
}
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: H. Peter Anvin @ 2006-04-08 20:27 UTC (permalink / raw)
To: Sam Ravnborg, Herbert Xu; +Cc: linux-kernel, akpm, mm-commits
In-Reply-To: <20060408201412.GA26946@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Sat, Apr 08, 2006 at 12:05:54AM -0700, akpm@osdl.org wrote:
>> diff -puN usr/dash/mkbuiltins~git-klibc-mktemp-fix usr/dash/mkbuiltins
>> --- 25/usr/dash/mkbuiltins~git-klibc-mktemp-fix Sat Apr 8 14:51:11 2006
>> +++ 25-akpm/usr/dash/mkbuiltins Sat Apr 8 14:51:11 2006
>> @@ -37,7 +37,7 @@
>>
>> tempfile=tempfile
>> if ! type tempfile > /dev/null 2>&1; then
>> - tempfile=mktemp
>> + tempfile="mktemp /tmp/tmp.XXXXXX"
>
> Shouldn't that be:
>> + tempfile="$(mktemp /tmp/tmp.XXXXXX)"
>
No, it's invoked later on as:
temp=$($tempfile)
temp2=$($tempfile)
Either which way; I have a better fix for the bison issue (this all has
to do with the fact that make's handling of tools that output more than
one file at a time is at the very best insane); however, I'm getting
rather unhappy with some of the code in dash.
In particular, mksyntax.c seems to assume it runs on the same machine
that the resulting code is going to execute on, for example, it tries to
detect whether or not "char" is signed, but that doesn't work when
cross-compiling.
dash isn't actually necessary in the in-kernel build, although it's a
very nice bonus for customizing initramfs to have a shell to glue things
together with.
Herbert: can the code be restructured with appropriate casts so that
signed/unsigned is factored out of mksyntax? As it currently stands,
it's not cross-compile-safe, which is unacceptable.
-hpa
^ permalink raw reply
* Re: [PATCH] Fix test for command line syntax.
From: Peter Eriksen @ 2006-04-08 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <20060408202450.GA5548@bohr.gbar.dtu.dk>
On Sat, Apr 08, 2006 at 10:24:50PM +0200, Peter Eriksen wrote:
>
> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
>
>
> ---
>
> test-delta.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Please ignore this. Sorry for the noise.
Peter
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Leonardo E. Reiter @ 2006-04-08 20:29 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381AE0.1020106@wasp.net.au>
I saw something like this once but dismissed it for some reason (like it
was questionable whether or not Windows supported these types of
devices)... it's quite interesting.
Thanks,
- Leo Reiter
Brad Campbell wrote:
> This link might or might not be intersting
>
> http://72.14.203.104/search?q=cache:fZ3xQJYOy6UJ:www.codecomments.com/archive421-2005-5-499360.html+hid+mouse+absolute+support&hl=en&ct=clnk&cd=1&lr=lang_en
>
>
> Apparently USB HID supports absolute input devices natively. Given we
> have a HID mouse driver of sorts in qemu I wonder if that is another
> avenue perhaps ?
>
>
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-08 20:30 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-08-2006 22:30 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
buboleck - 04-08-06 00:44
----------------------------------------------------------------------
ok. can you direct me please how to describe it?
----------------------------------------------------------------------
mborsick - 04-08-06 22:30
----------------------------------------------------------------------
Been following this, but have been unable to jump in because of other IT
projects I am working on here. Do you want me to file this with the linnux
kernel folks?
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
04-08-06 00:02 rlrevell Note Added: 0009163
04-08-06 00:16 buboleck Note Added: 0009164
04-08-06 00:19 buboleck Note Added: 0009165
04-08-06 00:29 rlrevell Note Added: 0009166
04-08-06 00:32 buboleck Note Added: 0009167
04-08-06 00:41 rlrevell Note Added: 0009168
04-08-06 00:42 buboleck Note Added: 0009169
04-08-06 00:44 buboleck Note Edited: 0009169
04-08-06 22:30 mborsick Note Added: 0009173
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [LARTC] source routing does not work with extra ip addresses
From: Martin A. Brown @ 2006-04-08 20:31 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060408123017.4a108613.mailinglists@lucassen.org>
Hello again,
: > Does server have one or two IP addresses? Best solution? Use two
: > IP addresses on server.
:
: Hmmm, one for ISP1 and one for ISP2? That would be a nice idea to
: workaround this problem :-)
Only way I have done this myself, although I recall somebody else on
LARTC using connmark with nfmark and/or the ROUTE target to solve
this problem using only a single IP. Perhaps the archive will help
you here....
: > Try changing this (or adding another rule):
: >
: > ip rule add from 10.0.0.2 lookup table_eth1
:
: Nope. I already tried that, but no way.
: No. The packets are returned through ISP1.
:
: > If you would like to handle inbound traffic on both links, then add
: > a secondary IP address to your server, and enter another DNAT rule
: > which specifies another NAT mapping for the secondary IP.
:
: That's a very nice idea, but packets keep on entering the wrong
: table (default), I think it's a bug somewhere in the kernel.
While the kernel certainly has seen bugs before and will see more, I
hope you don't mind if I continue to entertain a bit of skepticism
on this point. :)
: It only works when the ip is direct on the external interface of
: the Linuxbox, but as soon as 1 tcp port is translated, the return
: packets for that translated port get into the wrong (default)
: table.
:
: Even when using fw marks it doesn't work. I mark all packets coming
: from the servers second ip address with '1' and a simple
:
: ip ru a fwmark 1 table t_eth1
:
: should do the job. But no way. Packets keep on getting out
: through ISP1 (t_eth0).
:
: This is the real test:
:
: 10.0.2.1 is the server, 10.0.2.3 is its second ip.
: 10.0.2.1 = external 10.1.3.100
: 10.0.2.3 = external 192.168.201.3
OK, got it!
: # ip r s
: 192.168.201.3 via 10.0.2.3 dev eth2
: 10.1.3.100 via 10.0.2.1 dev eth2
[ snipped main and ancillary routing tables except for unusual and
possibly extraneous routes. ]
Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main
should be exactly the same. I believe your two host routes (for
192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate
your scenario.
I still think your problem is in the RPDB and addressing of the
packet at routing time. I do not believe (check the KPTD and its
offspring [0] [1]) that the packet's source address has yet been
rewritten. Think about this, and look at your RPDB:
: # ip ru s
: 0: from all lookup local
: 32762: from all fwmark 0x1 lookup t_eth1
: 32764: from 192.168.201.2 lookup t_eth1
: 32765: from 10.1.3.101 lookup t_eth0
: 32766: from all lookup main
: 32767: from all lookup default
The addresses you have entered are the public side addresses. When
the server transmits packets, these packets will have the 10.0.2.1
and 10.0.2.3 addresses for source addresses. The RPDB should
include references to these private addresses instead of the
addresses available on the public side.
: btw: iproute2-ss06011, kernel 2.6.16.2, iptables 1.3.5
I hope this helps, and thanks for the detailed listing of your
configuration. It's always helpful.
Best of luck,
-Martin
[0] http://www.docum.org/docum.org/kptd/
[1] http://linux-ip.net/nf/nfk-traversal.eps
http://linux-ip.net/nf/nfk-traversal.png
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@wonderfrog.net
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.