* Re: cross automount issue
From: Ian Kent @ 2006-04-09 4:19 UTC (permalink / raw)
To: Joe Pruett; +Cc: autofs
In-Reply-To: <Pine.LNX.4.64.0604070923300.15746@q7.q7.com>
On Fri, 7 Apr 2006, Joe Pruett wrote:
> after sending it, i started wondering what the lock was there for. i wasn't
> sure if each automount daemon was multi-threaded or not. what mount locking
> are you referring to?
The lock was introduced to prevent corruption of /etc/mtab because the
locking in mount for this purpose didn't work.
There are patches for mount which I believe fix it.
Ian
^ permalink raw reply
* [Ocfs2-devel] using ethernet instead of TCP
From: Wim Coekaerts @ 2006-04-09 4:13 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77DCEBF59@trantor>
nope not yet :)
On Sun, Apr 09, 2006 at 01:56:32PM +1000, James Harper wrote:
> Has anyone considered having the option of using Ethernet instead of TCP
> for inter-node communications? Such a feature would be useful for me as
> I'd like to use the same Ethernet segment for inter-node communication
> as I run AoE over (much less chance of a split brain), but I don't
> currently run IP on that segment. Also, running ocfs2 as the root
> filesystem would be easier (I've asked on -users if this is a good idea,
> as discussion of that aspect probably isn't appropriate to -devel) as IP
> wouldn't need to be started before bringing the root filesystem online.
>
> Obviously it's going to limit the cluster to the one lan segment, and
> you get a lot of stuff 'for free' with TCP that would have to be written
> for ocfs2 to use Ethernet (but I don't know how much the inter-node
> stuff actually makes use of it), so it might be too much work for too
> little gain...
>
> Thanks
>
> James
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel
^ permalink raw reply
* [LARTC] Simultaneous iptables calls
From: Daniel Webb @ 2006-04-09 4:12 UTC (permalink / raw)
To: lartc
Run this as one process:
#!/bin/sh
while [ 1 = 1 ]; do
iptables -t mangle -F chain1
iptables -t mangle -X chain1
iptables -t mangle -N chain1 || exit 1
done
Run this as another process:
#!/bin/sh
while [ 1 = 1 ]; do
iptables -t mangle -F chain2
iptables -t mangle -X chain2
iptables -t mangle -N chain2 || exit 1
done
and you get:
iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables: Chain already exists
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables: Unknown error 4294967295
iptables v1.3.5: can't initialize iptables table `mangle': Bad file descriptor
Perhaps iptables or your kernel needs to be upgraded.
<... etc>
I'm don't understand the things going on under the surface, so maybe there is
a reason it's impossible to have some kind of locking to prevent this, like
for example, with chmod:
#!/bin/sh
while [ 1 = 1 ]; do
chmod 777 mod_me
done
#!/bin/sh
while [ 1 = 1 ]; do
chmod 666 mod_me
done
(no errors)
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Patrick McHardy @ 2006-04-09 4:09 UTC (permalink / raw)
To: vherva; +Cc: linux-kernel
In-Reply-To: <20060408200915.GN1686@vianova.fi>
Ville Herva wrote:
> 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?
Most likely you didn't enable the new xtables options. Please post your
full config.
^ permalink raw reply
* Total Language Solution
From: Jason @ 2006-04-09 3:58 UTC (permalink / raw)
To: linux-scsi
Dear Sir,
We would like to take this opportunity to introduce our company.
We are a professional translation company£¬one of China¡¯s leading translation & interpretation companies, dedicates herself in providing our clients with highly professional language solutions.
In a global marketplace distinguished by remarkable growth and consolidation, We provides many language solutions that will assist in effective communication and organizational development.
All of our existing clients are continually looking to acquire best language solutions in order to improve business process and break through bottle neck, which enables them to gain competitive advantages and attain commercial objectives.
With over 200 highly qualified translators and interpreters with local and international industrial experience, We generates revenue from a client list including over 60% of world top 1000 companies
By providing translation and interpretation services in different industries, WTC people are passionate to deliver premium products and services that meet all of your personal and company needs.
If you have any requirements, please feel free to contact us.
For more information, please reply to this.
Best regards
Jason
Account Exective: Jason
M P: 13482251975
Q Q: 87386590
email:haibinjia@yahoo.com.cn
JASON
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Ocfs2-devel] using ethernet instead of TCP
From: James Harper @ 2006-04-09 3:56 UTC (permalink / raw)
To: ocfs2-devel
Has anyone considered having the option of using Ethernet instead of TCP
for inter-node communications? Such a feature would be useful for me as
I'd like to use the same Ethernet segment for inter-node communication
as I run AoE over (much less chance of a split brain), but I don't
currently run IP on that segment. Also, running ocfs2 as the root
filesystem would be easier (I've asked on -users if this is a good idea,
as discussion of that aspect probably isn't appropriate to -devel) as IP
wouldn't need to be started before bringing the root filesystem online.
Obviously it's going to limit the cluster to the one lan segment, and
you get a lot of stuff 'for free' with TCP that would have to be written
for ocfs2 to use Ethernet (but I don't know how much the inter-node
stuff actually makes use of it), so it might be too much work for too
little gain...
Thanks
James
^ permalink raw reply
* Burn calories
From: Britney Yazzie @ 2006-04-09 3:51 UTC (permalink / raw)
To: sparclinux
Summer is coming, did you look in the mirror lately?
If you`re still overweight you MUST visit us:
http://051.inexpensiveformula.com
WE WILL HELP YOU!
alto you raj me, burp vest neuromuscular expansible . adriatic you artichoke me, reedy handicraftsmen .
shade you plaintiff me, metcalf buckwheat . perform you chime me, midwives resent dylan .
http://051.inexpensiveformula.com/rm/
^ permalink raw reply
* [PATCH] diffcore-rename: fix merging back a broken pair.
From: Junio C Hamano @ 2006-04-09 3:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vwtdzcvhb.fsf@assigned-by-dhcp.cox.net>
When a broken pair is matched up by rename detector to be merged
back, we do not want to say it is "dissimilar" with the
similarity index. The output should just say they were changed,
taking the break score left by the earlier diffcore-break run if
any.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diffcore-rename.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
c17de73d793ff20fce6bcc8427e5f10ab8a2a7c5
diff --git a/diffcore-rename.c b/diffcore-rename.c
index e992698..d57e865 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -54,12 +54,14 @@ static struct diff_rename_dst *locate_re
/* Table of rename/copy src files */
static struct diff_rename_src {
struct diff_filespec *one;
+ unsigned short score; /* to remember the break score */
unsigned src_path_left : 1;
} *rename_src;
static int rename_src_nr, rename_src_alloc;
static struct diff_rename_src *register_rename_src(struct diff_filespec *one,
- int src_path_left)
+ int src_path_left,
+ unsigned short score)
{
int first, last;
@@ -89,6 +91,7 @@ static struct diff_rename_src *register_
memmove(rename_src + first + 1, rename_src + first,
(rename_src_nr - first - 1) * sizeof(*rename_src));
rename_src[first].one = one;
+ rename_src[first].score = score;
rename_src[first].src_path_left = src_path_left;
return &(rename_src[first]);
}
@@ -198,7 +201,10 @@ static void record_rename_pair(int dst_i
fill_filespec(two, dst->sha1, dst->mode);
dp = diff_queue(NULL, one, two);
- dp->score = score;
+ if (!strcmp(src->path, dst->path))
+ dp->score = rename_src[src_index].score;
+ else
+ dp->score = score;
dp->source_stays = rename_src[src_index].src_path_left;
rename_dst[dst_index].pair = dp;
}
@@ -256,10 +262,10 @@ void diffcore_rename(struct diff_options
* that means the source actually stays.
*/
int stays = (p->broken_pair && !p->score);
- register_rename_src(p->one, stays);
+ register_rename_src(p->one, stays, p->score);
}
else if (detect_rename == DIFF_DETECT_COPY)
- register_rename_src(p->one, 1);
+ register_rename_src(p->one, 1, p->score);
}
if (rename_dst_nr == 0 || rename_src_nr == 0 ||
(0 < rename_limit && rename_limit < rename_dst_nr))
--
1.2.6.gad0b
^ permalink raw reply related
* Re: Page Migration: Make do_swap_page redo the fault
From: Hugh Dickins @ 2006-04-09 3:11 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604081430280.17911@schroedinger.engr.sgi.com>
On Sat, 8 Apr 2006, Christoph Lameter wrote:
> On Sat, 8 Apr 2006, Hugh Dickins wrote:
> >
> > Sure, those are long standing checks, necessary long before migration
> > came on the scene; whereas the check in do_swap_page was recently added
> > just for a page migration case, and now turns out to be redundant.
>
> Those two checks were added for migration together with the one we
> are removing now. Sounds like you think they additionally fix some other
> race conditions?
Of course, you're right - sorry. Whatever was I looking at,
to get it so confidently wrong? Dunno: scary.
But I do have to worry then. I'd missed the addition of those checks:
if they really are necessary, then the rules have changed in two
tricky areas I now need to re-understand. It'll take me a while.
Thanks for setting me straight.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: kernel vs user power management
From: Brown, Len @ 2006-04-09 3:06 UTC (permalink / raw)
To: Holger Macht; +Cc: thoenig, linux-acpi, linux-laptop, Andi Kleen
>On Sat 08. Apr - 02:42:12, Brown, Len wrote:
>> Timo, Holger,
>> Andi pointed me to your FOSDEM Linux Power Management presentation:
>>
>> http://en.opensuse.org/FOSDEM2006
>>
>> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
>>
>> And I'm glad to see you working on Linux Power Management.
>>
>> But I'm a little concerned that user-space and the kernel are
>> a little out of sync on a few things.
>>
>> I'm happy to see that the userspace p-state governor
>> is no longer enabled by default on SuSE systems.
>> While it was passable on servers with steady-state
>> workloads, it was very bad for laptops where the
>> machine spends a lot of time idle, but has short
>> bursts of processing need which userspace could
>> not detect. These laptops would spend virtually
>> all their time in Pn when using the userspace governor.
>
>To be honest, this observation suprises me a little bit. We did some
>measurements with userspace agains ondemand governor some time
>ago and did not notice any big differences in the results between them.
>Well, these tests are about 1 1/2 years ago, though, and there went some
>changes into the kernel until now ;-)
Yes, measurements show that ondemand as improved
considerably since its initial implementation.
It continues to improve today, though there is now smaller room for improvement.
Also, the other important thing to meausre here is *response time* --
not throughput. This will expose the benefits of switching quickly
via ondemand vs. slowly via userspace.
This is particularly important on interarctive workloads.
No, you'll not notice much, if any, difference for course grain things
like doing a kernel build or running a steady-state server workload.
>Nevertheless, we adjust the sampling rate in any case and
>currently set it to 333 milliseconds (that's configurable).
>We noticed if we use the
>default ondemand setting, the ondemand governor increases the frequency
>too often although there is not much to do which is also not
>helpful.
I have not observed the ondemand governor today switching up
more often than is helpful.
I speak for intel hardware, of course.
It might be that other hardware, which can not switch up and down
very quickly, not not benefit from ondemand and may be better
suited to userspace.
>But 333 milliseconds is maybe a bit too high, it's taken because
>of historical reasons.
>This value _was_ the default interval of our main event loop.
>I think I will lower it a bit.
Go ahead and tune userspace to work optimally on systems that can't run ondemand.
Systems that are able to run ondemand should not be running userspace
at all.
>Furthermore, we had some problems on multiprocessor systems in the past
>(about 1/2 year ago) with the ondemand governor. After some time the
>system was running (even some hours or even days) the machine locked up
>hard. Thus, we set the userspace governor by default on those systems
>where we never experienced such problems. At the moment I did
>only get one similar report where the root cause is not clear.
It is important that this failure be root caused and this
doubt be put behind us. Got a bug URL?
>So I stick to the
>ondemand governor in any case in newer releases. And such lockups are
>really hard to reproduce and to debug.
>
>Another argument was that speedstep_ich was not yet ready for ondemand
>which it is now IIRC.
speedstep-centrino and acpi-cpufreq support real p-states and can
can support ondemand. (indeed, these two drivers need to be merged into a single driver)
While older systems will use speedstep-ich, I don't expect to see much
use for it on modern systems. p4clockmod is just t-states,
and one could argue that it should not exist at all.
I don't know if the amd-specific drivers would work or not.
Last I heard their latency was too high, but maybe they've
fixed that.
There is a cpufreq architecture issue here here, of course.
the drivers make all the different states look the same
to the governors. But P-states and T-states are not the same,
they are very different.
>> The next step is to delete the userspace governor
>> as a valid governor selection entirely. If somebody
>> really wants manual control, they can still set the
>> limits within which "ondemand" will stay.
>
>In current code, I always try to use the ondemand governor at
>first and if that fails we automatically switch to the userspace
>implementation at runtime.
>
>This way has the advantage that we always get a working cpu
>frequency scaling support.. But it also has one big disadvantage, we do
>not get reports about not working ondemand governor so maybe
>we simply did fot notice the improvements in this area. For our stable
>releases, I will keep the current inplementation. For the unstable one,
>I will disable the
>autoswitching code and if it still works good then for a few
>month, I will remove the userspace implementation completely.
>It should not hurt to let
>the code in for some time and remove the visible configuration option,
>just to have fallback under strange circumstances. Would this
>be ok with you?
I think you'll need to keep the userspace backup scheme for systems
which have switching latency too high to load and run ondemand.
However, systems which can run ondemand, should never run userspace,
and providing userspace as an option on such systems is probably
not the right knob to present to administrators on those boxes.
>> I'm happy to see that clock throttling is not enabled by
>> default in recent SuSE release, at least on my laptop
>> which supports P-states.
>>
>> I'd like to see no option to enable clock-throttling on
>> systems that support real p-states.
>
>Yes, this is reasonable, indeen. Will do that. With p-states in this
>context, you mean cpufreq here?
throttling is always T-states.
cpufreq is usually p-states, but in the case of p4clockmod,
it is T-states also. As I mentioned above, cpufreq is doing
you a dis-service by hiding the difference from you
and really need to be enhanced to know (and export)
the difference.
>> It is useful only for workloads which have an infinite
>> amount of non-idle computing which you don't care how
>> slow it computes. For the vast majority of workloads
>> it just slows down the machine and delays the processor
>> from getting into idle where it can save a non-linear
>> amount of power. Further, there exist today systems which
>> will consume MORE power in deep C-states when throttled
>> vs. when not throttled.
>>
>> The other major topic is the user/kernel interface
>> for power management policy. there needs to be in-kernel
>> state for this, else the device drivers will have no low-latency
>> way to get the answer to the simple policy question of how
>they should
>> optimize for performance vs power at any given instant when they
>> recognize their device is idle.. this state should be controlled
>> by user space, but I think it is most practical for it to
>> be kernel resident.
>
>I'm not sure if I completely understand what you mean here. Do you mean
>the so called "runtime device power management"?
yes.
>If so, I fully agree with you. But I do not set a specific
>policy in the powersave code explicitely for that feature.
>If the policy information
>will go into the kernel, I will use and set this one, of course.
okay, great.
Yes, the kernel folks have known for years that this has to be done.
Hopefully progress will be made soon...
thanks,
-Len
^ permalink raw reply
* Re: [linux-lvm] Recovering data from a damaged LVM partition?
From: Shawn @ 2006-04-09 2:59 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <200604061545.09082.sgrover@open2space.com>
I managed to work out a method to recover the lost data. I've documented this
on my blog (http://grover.open2space.com/node/17), for anyone who may be
facing a similar problem.
Of course, I'm sure those more experienced with LVM may have suggestions, and
I'd be happy to hear them. The solution basically meant learning more about
LVM in general.
Shawn
On Thursday 06 April 2006 15:45, Shawn wrote:
> First post to this list, so please forgive me if I'm not on topic, or
> repeating a common issue.
>
> I have been asked to try to get data from a drive with a damaged partition.
> In the past I've done this with ddrescue, and then mounted the resulting
> image file. That's not working in this case because the partition in
> question was part of an LVM volume.
>
> My experience with LVM is not that great, as I've never seen a need for it
> on my systems. But, I've installed the LVM tools, and modified my kernel
> for LVM support, and can at least see the volume on the damaged drive now.
> But I want to focus on the image file, not the drive.
>
> So, the question is how to mount an image file of an LVM partition?
> Anytime I try the mount command, it's complaining about the file system
> type. I've tried the different options for the -t argument, (and am using
> the -o loop as well).
>
> I'm hesitant to run any of the LVM commands to create a volume set, or
> intialize a partition, for fear of loosing the data. (though I could run
> ddrescue again I suppose, as long as I don't touch the source drive).
>
> Does anyone have any experience here they'd care to share? Thanks.
>
> BTW, the disk in question is from a default install of Fedora Core 4, and
> the system only had a single drive. So LVM probably wasn't needed in this
> case, but the person that installed the system is not comfortable with the
> file system details.
>
> Shawn
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:59 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <44381019.9070507@win4lin.com>
Leonardo E. Reiter wrote:
> 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.
The driver isn't built into Windows. It's pretty easy to install though
and the way my patch works, the PS/2 mouse is used until it detects the
tablet has been enabled.
The Windows driver uses quite a bit more of the features of the tablet
than the X driver so there's a bit more work to do but nothing
extraordinary.
Regards,
Anthony Liguori
>
> 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.
>
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Peter Williams @ 2006-04-09 2:58 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel
In-Reply-To: <200604082331.56715.a1426z@gawab.com>
Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Can you try the attached mem-eater passing it the number of kb to be
>>> eaten.
>>>
>>> i.e. '# while :; do ./eatm 9999 ; done'
>>>
>>> This will print the number of bytes eaten and the timing in ms.
>>>
>>> Adjust the number of kb to be eaten such that the timing will be less
>>> than timeslice (120ms by default for spa). Switch to another vt and
>>> start pressing enter. A console lockup should follow within seconds for
>>> all spas except ebs.
>> This doesn't seem to present a problem (other than the eatme loop being
>> hard to kill with control-C) on my system using spa_ws with standard
>> settings. I tried both UP and SMP. I may be doing something wrong or
>> perhaps don't understand what you mean by a console lock up.
>
> Switching from one vt to another receives hardly any response.
Aah. Virtual terminals. I was using Gnome terminals under X.
>
> This is especially visible in spa_no_frills, and spa_ws recovers from this
> lockup somewhat and starts exhibiting this problem as a choking behavior.
>
> Running '# top d.1 (then shift T)' on another vt shows this choking behavior
> as the proc gets boosted.
>
>> When you say "less than the timeslice" how much smaller do you mean?
>
> This depends on your machine's performance. On my 400MhzP2 UP 128MB, w/
> spa_no_frills default settings, looping eatm 9999 takes 63ms per eat and
> causes the rest of the system to be starved. Raising kb to 19999 takes
> 126ms which is greater than the default 120ms timeslice and causes no system
> starvation.
>
> What numbers do you get?
For 9999 I get 20ms. I have 1GB of memory and no swapping is taking
place but with only 128MB it's possible that your system is swapping and
that could make the effect more pronounced.
But anyway, based on the evidence, I think the problem is caused by the
fact that the eatm tasks are running to completion in less than one time
slice without sleeping and this means that they never have their
priorities reassessed. The reason that spa_ebs doesn't demonstrate the
problem is that it uses a smaller time slice for the first time slice
that a task gets. The reason that it does this is that it gives newly
forked processes a fairly high priority and if they're left to run for a
full 120 msecs at that high priority they can hose the system. Having a
shorter first time slice gives the scheduler a chance to reassess the
task's priority before it does much damage.
The reason that the other schedulers don't have this strategy is that I
didn't think that it was necessary. Obviously I was wrong and should
extend it to the other schedulers. It's doubtful whether this will help
a great deal with spa_no_frills as it is pure round robin and doesn't
reassess priorities except when nice changes of the task changes
policies. This is one good reason not to use spa_no_frills on
production systems. Perhaps you should consider creating a child
scheduler on top of it that meets your needs?
Anyway, an alternative (and safer) way to reduce the effects of this
problem (while your waiting for me to do the above change) is to reduce
the size of the time slice. The only bad effects of doing this is that
you'll do slightly worse (less than 1%) on kernbench.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:57 UTC (permalink / raw)
To: balrogg, qemu-devel
In-Reply-To: <fb249edb0604081221w1228728hc7c885892d9da7de@mail.gmail.com>
andrzej zaborowski wrote:
> Hi,
>
>
>
>> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
>> support is rather flakey: You have to disable mouse acceleration of the
>> guest OS.
>>
>> I had that cunning plan to write a virtual Wacom tablet, but I just don't
>> find the time.
>>
>>
> 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.
>
No, it supports all three. Works quite well for new X drivers. If you
search the wacom-devel archives you'll find a link to the docs for the
Wacom driver.
It does kind of suck though that you have to manually configure your X
server. I looked at a number of tablets and they all seem to be serial
or undocumented.
Regards,
Anthony Liguori
> 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.
>
>> Ciao,
>> Dscho
>>
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>
>
> --
> balrog 2oo6
>
> Dear Outlook users: Please remove me from your address books
> http://www.newsforge.com/article.pl?sid=03/08/21/143258
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:55 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082112030.8325@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 8 Apr 2006, Jim C. Brown wrote:
>
>
>> On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote:
>>
>>> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
>>> support is rather flakey: You have to disable mouse acceleration of the
>>> guest OS.
>>>
>>> I had that cunning plan to write a virtual Wacom tablet, but I just don't
>>> find the time.
>>>
>>> Ciao,
>>> Dscho
>>>
>>>
>> 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 but as I
mentioned earlier, YMMV.
Regards,
Anthony Liguori
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:54 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082054320.8169@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 8 Apr 2006, Leonardo E. Reiter wrote:
>
>
>> this virtual Wacom tablet you refer to... is there a [free or built-in]
>> Windows 2000/XP driver associated with it that supports either no
>> acceleration and/or absolute positioning?
>>
>
> Frankly, I do not know if they are free. But as nobody pays me to play
> with QEmu, I do not care about Windows so much. And the Wacom drivers for
> Linux are free.
>
> BTW I prefer a virtual wacom tablet to Summagraphics, since kudzu (the
> hardware detection which is used in Knoppix) can detect it. Unfortunately
> just the USB version :-(
>
The USB version of the wacom tablet is not documented. Only the older
serial tablets are.
Regards,
Anthony Liguori
>> If so, perhaps I can look at implementing it in QEMU in my "spare" time
>> ;) Do you have a link to documentation and/or drivers?
>>
>
> Wow! What an offer! I have some documentation somewhere, I just had a
> look, and only found the Summagraphics documentation. I will look harder.
>
>
>> If the guest OS can't be easily told to not do any acceleration and/or
>> use absolute cursor positioning rather than relative moves, it's not
>> that helpful to have a new type of input device. I suspect a tablet
>> driver can be easily configured this way since design people who
>> probably use these devices want perfect precision between pointer and
>> screen - otherwise they'd probably just use a mouse/trackball. But you
>> can never be sure how Microsoft (or Wacom) decided to implement the
>> Windows version of the driver.
>>
>
> My favourite cartoonist, Jamiri, is very proud of his Wacom tablet. IIRC,
> it has an integrated LCD display. So, I assume absolute positioning is
> automatically switched on with that tablet.
>
>
>> 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.
>>
>> Thanks!
>>
>
> Thank you!
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:53 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060408190115.GA16963@jbrown.mylinuxbox.org>
Jim C. Brown wrote:
> On Sat, Apr 08, 2006 at 08:24:03PM +0200, Johannes Schindelin wrote:
>
>> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
>> support is rather flakey: You have to disable mouse acceleration of the
>> guest OS.
>>
>> I had that cunning plan to write a virtual Wacom tablet, but I just don't
>> find the time.
>>
>> Ciao,
>> Dscho
>>
>>
>
> Anthony Ligouri has written a patch for wacom support.
>
Docs are available for older Wacom tablets. I've not gotten the time to
update my patches to actually implement the full protocol according to
the docs. The version I wrote is based on a newer X driver so YMMV.
Regards,
ANthony Liguori
> However, when I combine this with the -no-sdl-grab patch I still see syncing
> issues.
>
>
^ permalink raw reply
* Re: [Qemu-devel] VNC terminal server?
From: Anthony Liguori @ 2006-04-09 2:52 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <Pine.LNX.4.63.0604082003380.7783@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 8 Apr 2006, Samuel Hunt wrote:
>
>
>> It occurs to me that this program would make an excellent basis for a VNC
>> terminal server.
>>
>
> Yeah, something like that has been done already:
> http://libvncserver.sourceforge.net/qemu/qemu-rfb13.patch.gz
>
> There is a notable update since rfb12 (which is a bit out of date
> _cough_): Nis Jorgensen has sent a patch to support scroll mice.
>
> IMHO the biggest obstacle to inclusion in mainline QEmu is that the mouse
> support is rather flakey: You have to disable mouse acceleration of the
> guest OS.
>
> I had that cunning plan to write a virtual Wacom tablet, but I just don't
> find the time.
>
Someone posted a virtual Synaptic tablet on xen-devel recently (Xen uses
qemu for VT support). If someone wants to pick it up and submit it to
qemu, that would solve this problem.
Regards,
Anthony Liguori
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply
* Re: git-diff-tree -B broken
From: Junio C Hamano @ 2006-04-09 2:51 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060409004605.GU27689@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> $ git-diff-tree -r -p -B -M 916d8240bfc8ef5b80780b1a32ebb83ed055a178 \
> 3c9324ea16c345fc0bc0f11041905ba714797e4a cg-mkpatch
> diff --git a/cg-mkpatch b/cg-mkpatch
> dissimilarity index 57%
> index 74fe917..c932bc9 100755
> --- cg-mkpatch
> +++ cg-mkpatch
> @@ -0,0 +0,0 @@
>
> and nothing else. I'm too tired to debug or bisect this (xdiff
> introduction is the obvious suspect, I guess), just didn't want this
> to slip into the looming 1.3.0 so reporting early.
Thanks.
There are two issues. One of them is addressed with the
attached patch, which is just an artifact of the xdiff
introduction.
Another issue is a bit bigger.
The changes to the sample cg-mkpatch is estimated to be big
enough to get broken, just in case if there is another file
whose postimage that is more similar than the postimage of
cg-mkpatch itself, so that it can be matched up with the other
file, but it is _not_ dissimilar enough that diffcore_break()
code marks it to be merged back together if pieces of the broken
pair do not get matched up with other files. And in this
particular case, since you are limiting the search space to a
single file, there is no other files to match, so the broken
pair should survive the rename detection match-up, and they
should be shown as a normal diff without dissimilarity index at
all.
The funny thing is, the broken pair are matched up with
themselves, with similarity index of 57% (they originally are
from the same filepair, so that is natural). So in this case,
rename code _should_ take notice. I'll work on a fix.
-- >8 --
diff --git a/diff.c b/diff.c
index ce98a90..e887410 100644
--- a/diff.c
+++ b/diff.c
@@ -145,8 +145,9 @@ static void emit_rewrite_diff(const char
struct diff_filespec *one,
struct diff_filespec *two)
{
- /* Use temp[i].name as input, name_a and name_b as labels */
int lc_a, lc_b;
+ diff_populate_filespec(one, 0);
+ diff_populate_filespec(two, 0);
lc_a = count_lines(one->data, one->size);
lc_b = count_lines(two->data, two->size);
printf("--- %s\n+++ %s\n@@ -", name_a, name_b);
^ permalink raw reply related
* Re: menuconfig search (Re: [rfc] fix Kconfig, hotplug_cpu is needed for swsusp)
From: Randy.Dunlap @ 2006-04-09 2:29 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: akpm, linux-kernel
In-Reply-To: <Pine.LNX.4.61.0604081030201.21887@yvahk01.tjqt.qr>
On Sat, 8 Apr 2006 10:42:46 +0200 (MEST) Jan Engelhardt wrote:
> >> I find it very confusing to use, since it returns too verbose text to skim
> >> through. Probably the search function should be split into "only search
> >> titles[*]" and "search description too".
> >
> >Re verbosity: do you know that menuconfig search (/) takes regular
> >expressions?
>
> Regexes are not mentioned in the "Help" menu.
It is mentioned in the Help text after one enters '/'.
│ Search for CONFIG_ symbols and display their relations. │
│ Regular expressions are allowed. │
│ Example: search for "^FOO" │
> >That could help someone limit the amount of output
> >from it.
> >Can you give an example of being too verbose?
>
> / UNIX
> Symbol: UNIX [=y]
> Prompt: Unix domain sockets
> Defined at net/unix/Kconfig:5
> Depends on: NET
> Location:
> -> Networking
> -> Networking support (NET [=y])
> -> Networking options
>
> Symbol: UNIXWARE_DISKSLICES ...
> ...
>
>
> What would be more useful:
> UNIX
> Unix domain sockets
> Networking > Networking Support > Networking options
>
> UNIXWARE_DISKSLICES
> Unixware slices support
> File systems > Advanced ...
>
> I.e. strip the Defined and Depends lines and crunch the Location lines inasfar
> as that the full width of the window is used (break at col 70).
I don't see any need to limit it to 70 columns wide. It knows how to
scroll left/right (using arrow keys).
> DEEP_FS
> Just a symbol
> File systems > Advanced filesystems > Very advanced filesystems >\n
> Extremely advanced filesystems > Deep filesystem
>
>
> >I have just modified menuconfig search to make displaying the
> >Selects: and Selected by: output be an option (actually it's a
> >different search command (\) to not see those lines.
> >Would that help any regarding verbosity?
>
> At the moment, entering e.g. UNIX in both the / and \ menus return the very
> same output. Bug?
>
> The \ should include everything what the original / had, plus the symbol
> description ("Say Y here if ....").
Nope, the only thing that the "reduced" search excludes atm is SELECT info.
>From my original email, as you quoted above, the less-verbose '\' search
only eliminates the Selects: and Selected by: output, and the UNIX
config symbols don't have any SELECT info.
I don't know if we are converging any, but I made a new patch:
http://www.xenotime.net/linux/patches/menuconfig-search2b.patch
This one changes the default '/' search to NOT be verbose and the
new, extended '\' search to be verbose. The non-verbose search omits
Selects:, Selected by:, and Location: information.
---
~Randy
^ permalink raw reply
* PAE in 3.0.2
From: Brian Hays @ 2006-04-09 2:20 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 133 bytes --]
I've noticed that the download repo doesn't have a PAE (32p) install build.
Is PAE currently broken in 3.0.2?
Thank you,
Brian
[-- Attachment #1.2: Type: text/html, Size: 142 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Userland swsusp failure (mm-related)
From: Nick Piggin @ 2006-04-09 1:51 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Pavel Machek, Fabio Comolli, linux-kernel
In-Reply-To: <200604090047.17372.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> Hi,
>
>>>Well, it looks like we didn't free enough RAM for suspend in this case.
>>>Unfortunately we were below the min watermark for ZONE_NORMAL and
>>>we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
>>>ZONE_DMA in this case?).
>>>
>>>I think we can safely ignore the watermarks in swsusp, so probably
>>>we can set PF_MEMALLOC for the current task temporarily and reset
>>>it when we have allocated memory. Pavel, what do you think?
>>
>>Seems little hacky but okay to me.
>>
>>Should not fixing "how much to free" computation to free a bit more be
>>enough to handle this?
>
>
> Yes, but in that case we'll leave some memory unused. ;-)
>
Probably doesn't fall back to ZONE_DMA because of lowmem reserve.
Yes, PF_MEMALLOC sounds like it might do what you want. A little
hackish perhaps, but better than putting swsusp special cases
into page_alloc.c.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Maximum number of DomUs? (x86_64)
From: Florian Kirstein @ 2006-04-09 1:37 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
Hallo,
I just tried to push a quad-opteron server with 16GB of memory to the limit
and I reached it a bit earlier than expected. It seems that no matter
how much memory I assign to each DomU, and wether i use loopback or
phy/lvm devices for the storage, or no vif/storage at all, I can't
crate more than 107 DomUs (yes, that's not a real problem, I'm just
curious :) After No. 107 that I get(*):
Using config file "vm107".
Started domain VM107
Using config file "vm108".
Error: (12, 'Cannot allocate memory')
Using config file "vm109".
Error: (12, 'Cannot allocate memory')
but of course there's still memory left in Domain-0 to balloon out:
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 9215 4 r----- 319.3
VM1 1 64 1 ------ 0.8
VM10 10 64 1 -b---- 0.7
VM100 100 64 1 -b---- 0.4
When I assign 128MB per DomU exactly the same effect:
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 2372 4 r----- 2196.3
VM1 129 128 1 -b---- 0.4
VM10 138 128 1 -b---- 0.4
VM100 228 128 1 -b---- 0.2
So I wonder, which structure could run out of memory there? Is this a known
limitation? Didn't find much about the maximum number of DomUs
in the list archives... The Dom0 is running a CentOS4 x86_64 and I don't
even need a DomU image to reach this limit, network and diskless DomUs
just running into an "no root filesystem" panic being "preserve"d after
the crash have the same effect.
(:ul8er, r@y
(*) yes, I know, I could have used a vmid parameter instead of creating
100s of configfiles :)
^ permalink raw reply
* [Qemu-devel] qemu ./Makefile.target ./vl.c ./vl.h hw/integra...
From: Paul Brook @ 2006-04-09 1:32 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/09 01:32:52
Modified files:
. : Makefile.target vl.c vl.h
hw : integratorcp.c pl110.c
Added files:
hw : arm_pic.c arm_pic.h arm_timer.c pl011.c pl050.c
pl080.c pl190.c versatilepb.c
Log message:
ARM Versatile Platform Baseboard emulation.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.93&tr2=1.94&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.167&tr2=1.168&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.106&tr2=1.107&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_pic.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_pic.h?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/arm_timer.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/integratorcp.c.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl011.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl050.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl080.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl110.c.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/pl190.c?rev=1.1
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/versatilepb.c?rev=1.1
^ permalink raw reply
* Re: [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Dan Dennedy @ 2006-04-09 1:25 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, Adrian Bunk, scjody, linux-kernel
In-Reply-To: <443813C4.9090000@s5r6.in-berlin.de>
On Saturday 08 April 2006 12:49, Stefan Richter wrote:
> Dan Dennedy wrote:
> > 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.
> >
> It appears from grep'ing through the sources of Ekiga 2.0.1 that it does
> not access (lib)raw1394 by itself.
I just checked, and it is actually in the openh323 pwlib's vidinput_avc
module.
^ 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.