* Re: Feature wish: Cloning without history
From: Jakub Narebski @ 2006-05-18 19:35 UTC (permalink / raw)
To: git
In-Reply-To: <20060518192144.15912.qmail@web25913.mail.ukl.yahoo.com>
Sven Ekman wrote:
> Would it be possible to add an option to git-clone to
> skip the complete history? The result should be a
> repository which contains the current head only (or
> maybe a specified tag) and has that commit id added to
> .git/info/grafts. For the fetch process, this would
> certainly have to imply the --no-tags flag.
It is certainly reccuring request.
Check for "shallow clone" in git mailing list archives.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [git pull] Please pull infiniband.git
From: Roland Dreier @ 2006-05-18 19:33 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, openib-general
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
The changes and patch are:
Ishai Rabinovitz:
IB/srp: Complete correct SCSI commands on device reset
Michael S. Tsirkin:
IB/mthca: Fix posting lists of 256 receive requests for Tavor
Roland Dreier:
IB/mthca: Make fw_cmd_doorbell default to 0
IB/srp: Don't wait for disconnection if sending DREQ fails
IB/srp: Get rid of extra scsi_host_put()s if reconnection fails
IB/uverbs: Don't leak ref to mm on error path
drivers/infiniband/core/uverbs_mem.c | 4 +++-
drivers/infiniband/hw/mthca/mthca_cmd.c | 2 +-
drivers/infiniband/hw/mthca/mthca_qp.c | 35 ++++++++++++++++---------------
drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++-----
4 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_mem.c b/drivers/infiniband/core/uverbs_mem.c
index 36a32c3..efe147d 100644
--- a/drivers/infiniband/core/uverbs_mem.c
+++ b/drivers/infiniband/core/uverbs_mem.c
@@ -211,8 +211,10 @@ void ib_umem_release_on_close(struct ib_
*/
work = kmalloc(sizeof *work, GFP_KERNEL);
- if (!work)
+ if (!work) {
+ mmput(mm);
return;
+ }
INIT_WORK(&work->work, ib_umem_account, work);
work->mm = mm;
diff --git a/drivers/infiniband/hw/mthca/mthca_cmd.c b/drivers/infiniband/hw/mthca/mthca_cmd.c
index 1985b5d..798e13e 100644
--- a/drivers/infiniband/hw/mthca/mthca_cmd.c
+++ b/drivers/infiniband/hw/mthca/mthca_cmd.c
@@ -182,7 +182,7 @@ struct mthca_cmd_context {
u8 status;
};
-static int fw_cmd_doorbell = 1;
+static int fw_cmd_doorbell = 0;
module_param(fw_cmd_doorbell, int, 0644);
MODULE_PARM_DESC(fw_cmd_doorbell, "post FW commands through doorbell page if nonzero "
"(and supported by FW)");
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c
index 19765f6..07c13be 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -1727,23 +1727,7 @@ int mthca_tavor_post_receive(struct ib_q
ind = qp->rq.next_ind;
- for (nreq = 0; wr; ++nreq, wr = wr->next) {
- if (unlikely(nreq == MTHCA_TAVOR_MAX_WQES_PER_RECV_DB)) {
- nreq = 0;
-
- doorbell[0] = cpu_to_be32((qp->rq.next_ind << qp->rq.wqe_shift) | size0);
- doorbell[1] = cpu_to_be32(qp->qpn << 8);
-
- wmb();
-
- mthca_write64(doorbell,
- dev->kar + MTHCA_RECEIVE_DOORBELL,
- MTHCA_GET_DOORBELL_LOCK(&dev->doorbell_lock));
-
- qp->rq.head += MTHCA_TAVOR_MAX_WQES_PER_RECV_DB;
- size0 = 0;
- }
-
+ for (nreq = 0; wr; wr = wr->next) {
if (mthca_wq_overflow(&qp->rq, nreq, qp->ibqp.recv_cq)) {
mthca_err(dev, "RQ %06x full (%u head, %u tail,"
" %d max, %d nreq)\n", qp->qpn,
@@ -1797,6 +1781,23 @@ int mthca_tavor_post_receive(struct ib_q
++ind;
if (unlikely(ind >= qp->rq.max))
ind -= qp->rq.max;
+
+ ++nreq;
+ if (unlikely(nreq == MTHCA_TAVOR_MAX_WQES_PER_RECV_DB)) {
+ nreq = 0;
+
+ doorbell[0] = cpu_to_be32((qp->rq.next_ind << qp->rq.wqe_shift) | size0);
+ doorbell[1] = cpu_to_be32(qp->qpn << 8);
+
+ wmb();
+
+ mthca_write64(doorbell,
+ dev->kar + MTHCA_RECEIVE_DOORBELL,
+ MTHCA_GET_DOORBELL_LOCK(&dev->doorbell_lock));
+
+ qp->rq.head += MTHCA_TAVOR_MAX_WQES_PER_RECV_DB;
+ size0 = 0;
+ }
}
out:
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index c32ce43..9cbdffa 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -340,7 +340,10 @@ static void srp_disconnect_target(struct
/* XXX should send SRP_I_LOGOUT request */
init_completion(&target->done);
- ib_send_cm_dreq(target->cm_id, NULL, 0);
+ if (ib_send_cm_dreq(target->cm_id, NULL, 0)) {
+ printk(KERN_DEBUG PFX "Sending CM DREQ failed\n");
+ return;
+ }
wait_for_completion(&target->done);
}
@@ -351,7 +354,6 @@ static void srp_remove_work(void *target
spin_lock_irq(target->scsi_host->host_lock);
if (target->state != SRP_TARGET_DEAD) {
spin_unlock_irq(target->scsi_host->host_lock);
- scsi_host_put(target->scsi_host);
return;
}
target->state = SRP_TARGET_REMOVED;
@@ -365,8 +367,6 @@ static void srp_remove_work(void *target
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
scsi_host_put(target->scsi_host);
- /* And another put to really free the target port... */
- scsi_host_put(target->scsi_host);
}
static int srp_connect_target(struct srp_target_port *target)
@@ -1241,7 +1241,7 @@ static int srp_reset_device(struct scsi_
list_for_each_entry_safe(req, tmp, &target->req_queue, list)
if (req->scmnd->device == scmnd->device) {
req->scmnd->result = DID_RESET << 16;
- scmnd->scsi_done(scmnd);
+ req->scmnd->scsi_done(req->scmnd);
srp_remove_req(target, req);
}
^ permalink raw reply related
* Re: [PATCH 2/4] KBUILD: export-type enhancement to modpost.c
From: Jindrich Makovicka @ 2006-05-18 19:31 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060510235546.510C347002F@localhost>
On Wed, 10 May 2006 16:55:46 -0700 (PDT)
linuxram@us.ibm.com (Ram Pai) wrote:
> + if ((strcmp(export, "EXPORT_SYMBOL_GPL")))
I suppose there should be also == 0 like below, otherwise it fails on
any EXPORT_SYMBOL_GPL.
> + export_type = 1;
> + else if(strcmp(export, "EXPORT_SYMBOL") == 0)
> + export_type = 0;
> + else
> goto fail;
Regards,
--
Jindrich Makovicka
^ permalink raw reply
* python bindings: xen.lowlevel.xc.error
From: Kaleb Pederson @ 2006-05-18 19:31 UTC (permalink / raw)
To: xen-devel
Hello,
I don't see any way to get at the exception class that is being used by
xen.lowlevel.xc. I wanted to be able to grab just the xen exceptions,
but it doesn't appear possible:
>>> import xen.lowlevel.xc as xc
>>> dir(xc)
['__doc__', '__file__', '__name__', 'xc']
# the only thing listed is the xc class
# i'm running 3.0.2 using the sedf scheduler, so this should fail
>>> try:
... x.bvtsched_domain_get(0)
... except Exception, e:
... print e.__class__
... print dir(e)
... print dir(e.__class__)
... print e.__module__
... print e.args
...
xen.lowlevel.xc.error
['__doc__', '__getitem__', '__init__', '__module__', '__str__',
'args']
['__doc__', '__getitem__', '__init__', '__module__', '__str__']
xen.lowlevel.xc
(22, 'Invalid argument')
>>> e
<xen.lowlevel.xc.error instance at 0xb7b78b2c>
>>> xc.error
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'error'
Did I miss something? If not, could the xen.lowlevel.xc.error class be
publically exposed?
Thanks.
--Kaleb
^ permalink raw reply
* Re: replacing X Window System !
From: linux cbon @ 2006-05-18 19:31 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: helge.hafting, Valdis.Kletnieks, linux-kernel
In-Reply-To: <m2odxvdv2o.fsf@vador2.mandriva.com>
--- Thierry Vignaud <tvignaud@mandriva.com> a écrit :
> linux cbon <linuxcbon@yahoo.fr> writes:
>
> > Why dont we have "good" 3D support in X ?
>
> no documentation how to program nvidia 3d chips?
> or for the very latest ati chips?
> or from the XYZ vendor?
> ....
What do you think about this :
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893&w=2
But let me be clear -- the X developers are a bunch of
shameless vendor-loving lapdogs who sure are taking
their time at solving this > 10 year old problem!
They spend way more time chasing the latest vendor
binary loaded device driver, than they do solving this
obvious
problem. (Translation: They don't want to change how
X works, because it would break the vendor binary
drivers from ATI and NVIDIA. That is part of what
happens when X developers get jobs at vendors).
They've had 10 years, and yet every year they get more
entrenched in the entirely insecure model of "gigantic
process running as root, which accesses registers like
mad".
This problem is ENTIRELY the X group's fault! They
have failed us. Ten years ago they were laughing at
Microsoft for moving their video subsystem into their
kernel, but now the joke is on the X developers,
because what Microsoft did solved all these driver
security problems!
This is 100% an X server bug. It is not a hardware
bug, and it is not an operating system bug.
and this
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114233317926101&w=2
Some of our architectures use a tricky and horrid
thing to allow X to run. This is due to modern PC
video card architecture containing a large quantity of
PURE EVIL. To get around this evil the X developers
have done some rather expedient things, such as
directly accessing the cards via IO registers,
directly from userland. It is hard to see how they
could have done other -- that is how much evil the
cards contain.
> "belong to the OS" != "belong in the kernel"
> and where do you put the boundary of the OS? most
> people don't say
> that the OS is only the kernel...
Dont play with words. You know I meant graphics do
belong to the kernel. I didnt mean graphics belong to
gnu tools.
> like if xorg wasn't trying to improve x11 status
> (slowly trying to
> isolate priviliged stuff, introducing xcb, ...)
See above.
> > What is your opinion ?
>
> stop troll^h^h^h^h^h thread?
If I am a troll, then who are Theo or Linus ?
Thanks
___________________________________________________________________________
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel.
Rendez-vous sur http://fr.yahoo.com/set
^ permalink raw reply
* Re: auditctl usage for filter lists: "user" , "watch" and "exclude"
From: Steve Grubb @ 2006-05-18 19:29 UTC (permalink / raw)
To: Michael C Thompson; +Cc: linux-audit
In-Reply-To: <446CC4A3.2010409@us.ibm.com>
On Thursday 18 May 2006 15:01, Michael C Thompson wrote:
> Other than the source code, is there any place for a user to
> go and get the message types to determine their ordering?
Not at this point. I want to update the docs at some point...but until
then...source code.
-Steve
^ permalink raw reply
* Re: Query re: mempolicy for page cache pages
From: Lee Schermerhorn @ 2006-05-18 19:27 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, Andi Kleen, Steve Longerbeam, Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0605181105550.20557@schroedinger.engr.sgi.com>
On Thu, 2006-05-18 at 11:15 -0700, Christoph Lameter wrote:
> On Thu, 18 May 2006, Lee Schermerhorn wrote:
>
> > Below I've included an overview of a patch set that I've been working
> > on. I submitted a previous version [then called Page Cache Policy] back
> > ~20Apr. I started working on this because Christoph seemed to consider
> > this a prerequisite for considering migrate-on-fault/lazy-migration/...
> > Since the previous post, I have addressed comments [from Christoph] and
> > kept the series up to date with the -mm tree.
>
> The prequisite for automatic page migration schemes in the kernel is proof
> that these automatic migrations consistently improve performance. We are
> still waiting on data showing that this is the case.
So far, all I have is evidence that good locality obtained at process
start up using default policy is broken by internode task migrations.
I have seen this penalty fixed by automatic migration for artificial
benchmarks [McAlpin STREAM] and know that this approached worked well
for TPC-like loads on previous NUMA systems I've worked on. Currently,
I don't have access to TPC loads in my lab, but we're working on it.
And, if I could get the patches into the mm tree, once basic
migration settles down so as not to complicate your on-going work,
then folks could enable them to test the effects on their NUMA systems,
if they are at all concerned about load balancing upsetting previously
established locality. You know: the open source, community
collaboration
thing. I guess I thought that's what the mm tree is for. Not
everything
that gets in there makes it to Linus' tree.
>
> The particular automatic migration scheme that you proposed relies on
> allocating pages according to the memory allocation policy.
Makes emminent sense to me...
>
> The basic problem is first of all that the memory policies do not
> necessarily describe how the user wants memory to be allocated. The user
> may temporarily switch task policies to get specific allocation patterns.
> So moving memory may misplace memory. We got around that by
> saying that we need to separately enable migration if a user
> wants it.
I'm aware of this. I guess I always considered the temporary
switching of policies to achieve desired locality as a stopgap
measure because of missing capabilities in the kernel.
But, I agree that since this is the existing behavior and we don't
want to break user space, that it should be off by default and
enabled when desired. My latest patch series, which I haven't posted
for obvious reasons, does support per cpuset enabling of
migrate-on-fault and auto-migration.
>
> But even then we have the issue that the memory policies cannot
> describe proper allocation at all since allocation policies are
> ignored for file backed vmas. And this is the issue you are trying to
> address.
Right! For consistency's sake, I guess. I always looked at it as
the migrate-on-fault was "correcting" page misplacement at original
fault time. Said with tongue only slightly in cheek ;-).
>
> I think this is all far to complicated to do in kernel space and still
> conceptually unclean. I would like to have all automatic migration schemes
> confined to user space. We will add an API that allows some process
> to migrate pages at will.
We want pages to migrate when the load balancer decides to move the
process
to a new node, away from it's memory. I suppose internode migration
could also be accidently reuniting a task with its memory footprint,
but the higher the node count, the lower the probability of this. And,
if we did do some form of page migration on task migration, I think
we'd need to consider the cost of page migration in the decision to
migrate. I see that previous attempts to consider memory footprint in
internode migration seem to have gone nowhere, tho'. Probably not worth
it for some nominally numa platforms. Even for platforms where it
might make sense, tuning the algorithms will, I think, require data
that can best be obtained from testing on multiple platforms. Just
dreaming, I know...
As far as doing it in user space: I supposed one could deliver a
notification to the process and have it migrate pages at that point.
Sounds a lot more inefficient than just unmapping pages that have
default policy as the process returns to user space on the new node
[easy to hook in w/o adding new mechanism] and letting the pages fault
over as they are referenced. After all, we don't know which pages
will be touched before the next internode migration. I don't think
that the application itself would have a good idea of this at the
time of the migration.
And, I think, complication and cleanliness is in the eye of the
beholder.
'Nuf said on that point... ;-)
Lee
--
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: [PATCH 0/9] namespaces: Introduction
From: John Kelly @ 2006-05-18 19:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Serge E. Hallyn, linux-kernel, dev, herbert, devel, sam, ebiederm,
xemul, haveblue, clg, serue
In-Reply-To: <20060518103430.080e3523.akpm@osdl.org>
On Thu, 18 May 2006 10:34:30 -0700, Andrew Morton <akpm@osdl.org>
wrote:
>I see two ways of justifying a mainline merge of things such as this
>a) We make an up-front decision that Linux _will_ have OS-virtualisation
> capability in the future
After using OpenVZ for a short time, I wonder how I ever managed
without it. For application development and testing, having a little
sandbox with only a few PIDs running makes it easier to debug things.
> and just start putting in place the pieces for that, even if some
> of them are not immediately useful. I suspect that'd be acceptable,
> although I worry that we'd get partway through and some issues would
> come up which are irreconcilable amongst the various groups.
>From a user's POV, I want it ASAP. As for conflicts, why not cross
that bridge when you come to it?
^ permalink raw reply
* Feature wish: Cloning without history
From: Sven Ekman @ 2006-05-18 19:21 UTC (permalink / raw)
To: git
Hello,
Would it be possible to add an option to git-clone to
skip the complete history? The result should be a
repository which contains the current head only (or
maybe a specified tag) and has that commit id added to
.git/info/grafts. For the fetch process, this would
certainly have to imply the --no-tags flag.
>From a user's point of view I'd imagine something like
this:
git-clone --no-history=v2.6.16 \
git://git.kernel.org/.../linux-2.6.git
The background: I'm regularly building kernels for a
handful of machines, and while I am happy to use the
blessings of git to get updates from the -stable
releases, I see no point in wasting space for a copy
of the complete kernel history on every single
machine. In practice this works pretty good, once I
have manually created such a castrated repository.
Sven
^ permalink raw reply
* [Ocfs2-devel] Fencing in OCFS2
From: Daniel Phillips @ 2006-05-18 19:21 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <446CC185.9090306@oracle.com>
Zach Brown wrote:
> Sum Sha wrote:
>
>>With some experiments and going through OCFS2's quorum code, I am sure
>>that in case of serial split-brain, quorum algorithm will surely break
>>and will cause complete cluster shutdown. It will cause all the
>>subcluster nodes to panic themselves. Please correct me if I am
>>wrong...
>
> Can you provide the details that lead you to be sure of your analysis?
It seems to be the intended behavior. No node is a member of a quorum
group so all nodes should be fenced. This is correct.
What is wrong is the idea that fencing is equivalent to panicking. No!
Fencing means preventing a particular node from writing to shared storage.
The FAQ item is incorrect. How about this instead?
Q03 What is fencing?
A03 Fencing is the act of preventing a node from writing to shared
cluster storage.
Regards,
Daniel
^ permalink raw reply
* Re: Too many levels of symbolic links
From: Tim Pepper @ 2006-05-18 19:20 UTC (permalink / raw)
To: viro; +Cc: linux-kernel, Linda Walsh, Brian D. McGrew, H. Peter Anvin
In-Reply-To: <eada2a070605171358r1fea2c62u641b6308e78aa1e4@mail.gmail.com>
Nevermind..missed the subject changed follow up to this...
Tim
^ permalink raw reply
* Re: klibc and SPARC
From: H. Peter Anvin @ 2006-05-18 19:17 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <e4g1ho$dae$1@terminus.zytor.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
David S. Miller wrote:
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Wed, 17 May 2006 16:10:51 -0700
>
>> Well, I'm happy to do it either which way. I'll go ahead and write
>> up an ad hoc solution for this case, unless it turns out to actually
>> be bigger than one of the generic codes.
>
> Note you could export these specific values via procfs/sysfs.
>
> Just an idea...
After thinking about it some more, I decided to drop the information into a file in the
rootfs. That way there is no "normal runtime" memory footprint, which would be the main
reason to avoid the normal drivers.
The kernel side of the patch is attached for review; there is obviously also a kinit side
which I haven't written yet (I'll try to finish the whole thing this evening.)
-hpa
[-- Attachment #2: sparc64.arch.diff --]
[-- Type: text/x-patch, Size: 3033 bytes --]
diff --git a/arch/sparc64/kernel/setup.c b/arch/sparc64/kernel/setup.c
index 005167f..a124cb0 100644
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -102,7 +102,7 @@ int obp_system_intr(void)
return 0;
}
-/*
+/*
* Process kernel command line switches that are specific to the
* SPARC or that require special low-level processing.
*/
@@ -315,6 +315,53 @@ static void __init sun4v_patch(void)
}
}
+/*
+ * Platform-specific configuration commands which don't come from
+ * the actual kernel command line. Write them into a file in rootfs
+ * so kinit can pick them up.
+ */
+static void __init set_arch_init_commands(void)
+{
+ int fd = sys_open("/arch.cmd", O_WRONLY|O_CREATE|O_APPEND, 0666);
+ int chosen = prom_finddevice ("/chosen");
+ u32 cl, sv, gw;
+ char buffer[256];
+ int len = 0;
+
+ if (fd < 0)
+ return;
+
+ cl = prom_getintdefault (chosen, "client-ip", 0);
+ sv = prom_getintdefault (chosen, "server-ip", 0);
+ gw = prom_getintdefault (chosen, "gateway-ip", 0);
+
+#ifdef CONFIG_BLK_DEV_RAM
+ len = min(sizeof buffer - 1,
+ snprintf(buffer, sizeof buffer,
+ "ramdisk_start=%u\n"
+ "prompt_ramdisk=%d\n"
+ "load_ramdisk=%d\n",
+ ram_flags & RAMDISK_IMAGE_START_MASK,
+ !!(ram_flags & RAMDISK_PROMPT_FLAG),
+ !!(ram_flags & RAMDISK_LOAD_FLAG)));
+#endif
+ if (cl && sv) {
+ len += min(sizeof buffer - 1 - len,
+ snprintf(buffer+len, sizeof buffer - len,
+ "ip=%u.%u.%u.%u:%u.%u.%u.%u:"
+ "%u.%u.%u.%u\n",
+ (u8)(cl >> 24), (u8)(cl >> 16),
+ (u8)(cl >> 8), (u8)cl,
+ (u8)(sv >> 24), (u8)(sv >> 16),
+ (u8)(sv >> 8), (u8)sv,
+ (u8)(gw >> 24), (u8)(gw >> 16),
+ (u8)(gw >> 8), (u8)gw));
+ }
+
+ sys_write(fd, buffer, len);
+ sys_close(fd);
+}
+
void __init setup_arch(char **cmdline_p)
{
/* Initialize PROM console and command line. */
@@ -349,33 +396,10 @@ #endif
if (!root_flags)
root_mountflags &= ~MS_RDONLY;
ROOT_DEV = old_decode_dev(root_dev);
-#ifdef CONFIG_BLK_DEV_RAM
- rd_image_start = ram_flags & RAMDISK_IMAGE_START_MASK;
- rd_prompt = ((ram_flags & RAMDISK_PROMPT_FLAG) != 0);
- rd_doload = ((ram_flags & RAMDISK_LOAD_FLAG) != 0);
-#endif
task_thread_info(&init_task)->kregs = &fake_swapper_regs;
-#ifdef CONFIG_IP_PNP
- if (!ic_set_manually) {
- int chosen = prom_finddevice ("/chosen");
- u32 cl, sv, gw;
-
- cl = prom_getintdefault (chosen, "client-ip", 0);
- sv = prom_getintdefault (chosen, "server-ip", 0);
- gw = prom_getintdefault (chosen, "gateway-ip", 0);
- if (cl && sv) {
- ic_myaddr = cl;
- ic_servaddr = sv;
- if (gw)
- ic_gateway = gw;
-#if defined(CONFIG_IP_PNP_BOOTP) || defined(CONFIG_IP_PNP_RARP)
- ic_proto_enabled = 0;
-#endif
- }
- }
-#endif
+ set_arch_init_commands();
smp_setup_cpu_possible_map();
@@ -439,7 +463,7 @@ static int ncpus_probed;
static int show_cpuinfo(struct seq_file *m, void *__unused)
{
- seq_printf(m,
+ seq_printf(m,
"cpu\t\t: %s\n"
"fpu\t\t: %s\n"
"prom\t\t: %s\n"
^ permalink raw reply related
* [Printing-architecture] PAPI bug: "lpstat -v" uses /etc/printcap on CUPS system
From: Till Kamppeter @ 2006-05-18 19:16 UTC (permalink / raw)
To: Norm Jacobs, desktop_printing@osdl.org, printing-architecture
I am using the PAPI with the psm-ipp backend as CUPS is the spooler on
my Mandriva box. By default CUPS writes a pseudo /etc/printcap for
backwards compatibility. Therefore I did not get aware of the problem in
the first tests.
This writing of /etc/printcap can be turned off by putting a line only
containing "Printcap" into /etc/cups/cupsd.conf and then restarting the
CUPS daemon. After that I also deleted the last /etc/printcap which CUPS
keft over and entered
lpstat -v
again and then no print queue was listed. I cannot even print any more.
the "lpr" command tells me that the printer which I have specified does
not exist.
This means that without /etc/printcap libpapi does not work at all. And
as in CUPS printer enumeration is done via IPP and not via /etc/printcap
this is a real bug in libpapi.
The psm-ipp plug-in even has a function which uses an IPP extension of
CUPS to enumerate the printers, papiPrintersList() in libpapi-ipp/printer.c.
Very strange is also the output of
strace lpstat -v > x 2>&1
when CUPS does not write /etc/printcap. I have IPP set as compile-time
default for the print service module and in the strace output one can
see that lpstat fails to open /etc/printcap and then it decides to try
opening /usr/lib/psm-_all.so which also does not exist and probably
never existed. Why does lpstat check /etc/printcap? All communication
with the printing system should be done through the PSM backends, in my
case through /usr/lib/psm-ipp.so and this is never called in this case.
Till
^ permalink raw reply
* [PATCH] cpuid feature bits masking for HVM guests
From: Kamble, Nitin A @ 2006-05-18 19:11 UTC (permalink / raw)
To: Keir Fraser, Ian Pratt
Cc: Mallick, Asit K, Yu, Wilfred, xen-devel, Nakajima, Jun
[-- Attachment #1.1: Type: text/plain, Size: 479 bytes --]
Hi Keir, Ian,
Attached patch implements masking of some of the cupid bits from the
guest. It also cleans up the previous cupid handling code.
Please apply and/or comment.
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-Off-By: Jun Nakajima <jun.nakajima@intel.com>
Thanks & Regards,
Nitin
------------------------------------------------------------------------
-----------
Open Source Technology Center, Intel Corp
[-- Attachment #1.2: Type: text/html, Size: 3218 bytes --]
[-- Attachment #2: cpuid_9.patch --]
[-- Type: application/octet-stream, Size: 6975 bytes --]
diff -r 86d8246c6aff4974d96b9375c3747915bb858a26 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Wed May 17 22:15:36 2006
+++ b/xen/arch/x86/hvm/vmx/vmx.c Wed May 17 18:56:32 2006
@@ -38,6 +38,7 @@
#include <asm/hvm/support.h>
#include <asm/hvm/vmx/vmx.h>
#include <asm/hvm/vmx/vmcs.h>
+#include <asm/hvm/vmx/cpu.h>
#include <asm/shadow.h>
#if CONFIG_PAGING_LEVELS >= 3
#include <asm/shadow_64.h>
@@ -813,9 +814,6 @@
}
}
-/* Reserved bits: [31:15], [12:11], [9], [6], [2:1] */
-#define VMX_VCPU_CPUID_L1_RESERVED 0xffff9a46
-
static void vmx_vmexit_do_cpuid(struct cpu_user_regs *regs)
{
unsigned int input = (unsigned int)regs->eax;
@@ -832,50 +830,67 @@
(unsigned long)regs->ecx, (unsigned long)regs->edx,
(unsigned long)regs->esi, (unsigned long)regs->edi);
- if ( input == 4 )
+ if ( input == CPUID_LEAF_4 ) {
cpuid_count(input, count, &eax, &ebx, &ecx, &edx);
- else
+ eax &= NUM_CORES_RESET_MASK;
+ } else {
cpuid(input, &eax, &ebx, &ecx, &edx);
- if ( input == 1 )
- {
- if ( !hvm_apic_support(v->domain) ||
- !vlapic_global_enabled((VLAPIC(v))) )
+ if ( input == CPUID_LEAF_1 )
{
- clear_bit(X86_FEATURE_APIC, &edx);
- /* Since the apic is disabled, avoid any confusion about SMP cpus being available */
- clear_bit(X86_FEATURE_HT, &edx); /* clear the hyperthread bit */
- ebx &= 0xFF00FFFF; /* set the logical processor count to 1 */
- ebx |= 0x00010000;
- }
-
-
+ /* mask off reserved bits */
+ ecx &= ~VMX_VCPU_CPUID_L1_ECX_RESERVED;
+ edx &= ~VMX_VCPU_CPUID_L1_EDX_RESERVED;
+
+ if ( !hvm_apic_support(v->domain) ||
+ !vlapic_global_enabled((VLAPIC(v))) )
+ {
+ /* Since the apic is disabled, avoid any
+ confusion about SMP cpus being available */
+
+ clear_bit(X86_FEATURE_APIC, &edx);
+ }
+
#if CONFIG_PAGING_LEVELS < 3
- clear_bit(X86_FEATURE_PAE, &edx);
- clear_bit(X86_FEATURE_PSE, &edx);
- clear_bit(X86_FEATURE_PSE36, &edx);
-#else
- if ( v->domain->arch.ops->guest_paging_levels == PAGING_L2 )
- {
- if ( !v->domain->arch.hvm_domain.pae_enabled )
- clear_bit(X86_FEATURE_PAE, &edx);
+ clear_bit(X86_FEATURE_PAE, &edx);
clear_bit(X86_FEATURE_PSE, &edx);
clear_bit(X86_FEATURE_PSE36, &edx);
- }
+#else
+ if ( v->domain->arch.ops->guest_paging_levels == PAGING_L2 )
+ {
+ if ( !v->domain->arch.hvm_domain.pae_enabled )
+ clear_bit(X86_FEATURE_PAE, &edx);
+ clear_bit(X86_FEATURE_PSE, &edx);
+ clear_bit(X86_FEATURE_PSE36, &edx);
+ }
#endif
- /* Unsupportable for virtualised CPUs. */
- ecx &= ~VMX_VCPU_CPUID_L1_RESERVED; /* mask off reserved bits */
- clear_bit(X86_FEATURE_VMXE & 31, &ecx);
- clear_bit(X86_FEATURE_MWAIT & 31, &ecx);
- }
+ ebx &= NUM_THREADS_RESET_MASK;
+
+ /* Unsupportable for virtualised CPUs. */
+ ecx &= ~(bitmaskof(X86_FEATURE_VMXE) |
+ bitmaskof(X86_FEATURE_EST) |
+ bitmaskof(X86_FEATURE_TM2) |
+ bitmaskof(X86_FEATURE_CID) |
+ bitmaskof(X86_FEATURE_MWAIT) );
+
+ clear_bit(X86_FEATURE_ACPI, &edx);
+ clear_bit(X86_FEATURE_HT, &edx);
+ }
+ else if (( input >= CPUID_LEAF_5 )
+ && ( input < CPUID_LEAF_80000000 )) {
+ eax = ebx = ecx = edx = 0x0;
+ }
#ifdef __i386__
- else if ( input == 0x80000001 )
- {
- /* Mask feature for Intel ia32e or AMD long mode. */
- clear_bit(X86_FEATURE_LM & 31, &edx);
- }
+ else if ( input == CPUID_LEAF_80000001 )
+ {
+ clear_bit(X86_FEATURE_LAHF_LM & 31, &ecx);
+
+ clear_bit(X86_FEATURE_LM & 31, &edx);
+ clear_bit(X86_FEATURE_SYSCALL & 31, &edx);
+ }
#endif
+ }
regs->eax = (unsigned long) eax;
regs->ebx = (unsigned long) ebx;
diff -r 86d8246c6aff4974d96b9375c3747915bb858a26 xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h Wed May 17 22:15:36 2006
+++ b/xen/include/asm-x86/cpufeature.h Wed May 17 18:56:32 2006
@@ -79,7 +79,7 @@
#define X86_FEATURE_EST (4*32+ 7) /* Enhanced SpeedStep */
#define X86_FEATURE_TM2 (4*32+ 8) /* Thermal Monitor 2 */
#define X86_FEATURE_CID (4*32+10) /* Context ID */
-#define X86_FEATURE_CX16 (4*32+13) /* CMPXCHG16B */
+#define X86_FEATURE_CX16 (4*32+13) /* CMPXCHG16B */
#define X86_FEATURE_XTPR (4*32+14) /* Send Task Priority Messages */
/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */
@@ -95,6 +95,7 @@
#define cpu_has(c, bit) test_bit(bit, (c)->x86_capability)
#define boot_cpu_has(bit) test_bit(bit, boot_cpu_data.x86_capability)
+#define bitmaskof(bit) (0x1 << ((bit) & 31))
#ifdef __i386__
#define cpu_has_vme boot_cpu_has(X86_FEATURE_VME)
diff -r 86d8246c6aff4974d96b9375c3747915bb858a26 xen/include/asm-x86/hvm/vmx/cpu.h
--- a/xen/include/asm-x86/hvm/vmx/cpu.h Wed May 17 22:15:36 2006
+++ b/xen/include/asm-x86/hvm/vmx/cpu.h Wed May 17 18:56:32 2006
@@ -32,4 +32,37 @@
#define VMX_MF_32 1
#define VMX_MF_64 2
+#define CPUID_LEAF_1 0x1
+#define CPUID_LEAF_4 0x4
+#define CPUID_LEAF_5 0x5
+#define CPUID_LEAF_80000000 0x80000000
+#define CPUID_LEAF_80000001 0x80000001
+
+#define NUM_CORES_RESET_MASK 0x00003FFF
+#define NUM_THREADS_RESET_MASK 0xFF00FFFF
+
+#define VMX_VCPU_CPUID_L1_ECX_RESERVED_31_15 0xffff8000
+#define VMX_VCPU_CPUID_L1_ECX_RESERVED_12_11 0x00001800
+#define VMX_VCPU_CPUID_L1_ECX_RESERVED_6 0x00000040
+#define VMX_VCPU_CPUID_L1_ECX_RESERVED_2_1 0x00000006
+
+#define VMX_VCPU_CPUID_L1_ECX_RESERVED \
+ ( \
+ VMX_VCPU_CPUID_L1_ECX_RESERVED_31_15 | \
+ VMX_VCPU_CPUID_L1_ECX_RESERVED_12_11 | \
+ VMX_VCPU_CPUID_L1_ECX_RESERVED_6 | \
+ VMX_VCPU_CPUID_L1_ECX_RESERVED_2_1 \
+ )
+
+#define VMX_VCPU_CPUID_L1_EDX_RESERVED_30 0x40000000
+#define VMX_VCPU_CPUID_L1_EDX_RESERVED_20 0x00100000
+#define VMX_VCPU_CPUID_L1_EDX_RESERVED_10 0x00000400
+
+#define VMX_VCPU_CPUID_L1_EDX_RESERVED \
+ ( \
+ VMX_VCPU_CPUID_L1_EDX_RESERVED_30 | \
+ VMX_VCPU_CPUID_L1_EDX_RESERVED_20 | \
+ VMX_VCPU_CPUID_L1_EDX_RESERVED_10 \
+ )
+
#endif /* __ASM_X86_HVM_VMX_CPU_H__ */
[-- Attachment #3: 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: [patch] fix magic sysrq on strange keyboards
From: Andrew Morton @ 2006-05-18 19:10 UTC (permalink / raw)
To: Pavel Machek; +Cc: dtor_core, linux-input, vojtech, linux-kernel
In-Reply-To: <20060518102354.GA1715@elf.ucw.cz>
Pavel Machek <pavel@suse.cz> wrote:
>
> Magic sysrq fails to work on many keyboards, particulary most of
> notebook keyboards. This should help...
>
> The idea is quite simple: Discard the SysRq break code if Alt is still
> being held down. This way the broken keyboard can send the break code
> (or the user with a normal keyboard can release the SysRq key) and the
> kernel waits until the next key is pressed or the Alt key is released.
>
> From: Fredrik Roubert <roubert@df.lth.se>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
>
What kernel are you patching here?
> index 5d84839..4602cf3 100644
> --- a/drivers/char/keyboard.c
> +++ b/drivers/char/keyboard.c
> @@ -149,7 +149,8 @@ unsigned char kbd_sysrq_xlate[KEY_MAX +
> "\206\207\210\211\212\000\000789-456+1" /* 0x40 - 0x4f */
> "230\177\000\000\213\214\000\000\000\000\000\000\000\000\000\000" /* 0x50 - 0x5f */
> "\r\000/"; /* 0x60 - 0x6f */
> -static int was_sysrq;
> +static int sysrq_down;
> +static int sysrq_alt_use;
bix:/usr/src/linux-2.6.17-rc4> grep was_sysrq drivers/char/sysrq.c
bix:/usr/src/linux-2.6.17-rc4>
^ permalink raw reply
* Re: Query re: mempolicy for page cache pages
From: Lee Schermerhorn @ 2006-05-18 19:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, clameter, ak, stevel
In-Reply-To: <20060518111416.51de0127.akpm@osdl.org>
On Thu, 2006-05-18 at 11:14 -0700, Andrew Morton wrote:
> Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
> >
> > 1) What ever happened to Steve's patch set?
>
> They were based on Andi's 4-level-pagetable work. Then we merged Nick's
> 4-level-pagetable work instead, so
> numa-policies-for-file-mappings-mpol_mf_move.patch broke horridly and I
> dropped it. Steve said he'd redo the patch based on the new pagetable code
> and would work with SGI on getting it benchmarked, but that obviously
> didn't happen.
Thanks for the info Andrew.
>
> I was a bit concerned about the expansion in sizeof(address_space), but we
> ended up agreeing that it's numa-only and NUMA machines tend to have lots
> of memory anyway. That being said, it would still be better to have a
> pointer to a refcounted shared_policy in the address_space if poss, rather
> than aggregating the whole thing.
Yes, I was concerned about that, too. I do use a pointer to the shared
policy struct in the address space, allocating it only if one actually
applies a policy. A null pointer results in current behavior: fall
back
to process then global default policy. Even so, the pointer member
would
only be included under CONFIG_NUMA.
As far as reference counting: I didn't think it would be necessary,
because
it appears to me that the address space structs are one to one with the
inodes and persists as long as the inode does. Is this correct? If
so,
then the shared policy struct would only be deleted when the inode goes
away. I may have a race, but I didn't think one could be doing an
insert
or lookup w/o holding locks/references on structs that would prevent the
inode from being destroyed.
But, may turn out to be moot, heh?
Lee
--
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: mailing list filters?
From: Lee Revell @ 2006-05-18 19:09 UTC (permalink / raw)
To: Thomas Kuther; +Cc: alsa-devel
In-Reply-To: <20060518201722.2faedde3@SiRiUS.home>
On Thu, 2006-05-18 at 20:17 +0200, Thomas Kuther wrote:
> well it's like 90/10 S/N ratio, yes.
> My spamassassin runs hot with this list. *hint* :)
> (thank god for it!)
But, you can see in the headers that SF already runs everything through
SA. However some of the obvious spam gets a very low spam score (3-5).
Do you have any theory about that? Is SF's spamassassassin just poorly
tuned?
Lee
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* ptrace() - is kernel drop PT_PTRACED bit in task->ptrace?
From: Sergei I. Kononov @ 2006-05-18 19:08 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
All,
I wrote 2 small programms:
1 - daemonize itself in loop (forever) =)
2 - traces the fork/clone events via ptrace() interface.
You can find both in attachment.
The strange thing is that, when I'm trying to attach
to new process (after I've detached from old one), ptrace() returns -1
and errno is EPERM.
I examined kernel/ptrace.c source code and I suppose that I've found the reason for such
behaviour. In file kernel/ptrace.c in function ptrace_attach(task)
exists PT_PTRACED bit check:
...
if (task->ptrace & PT_PTRACED)
goto bad;
...
bad:
task_unlock(task);
return retval;
retval is set to -EPERM.
I didn't find place where PT_PTRACED bit drops, please point me to this place
if such exists.
Or maybe I do something wrong?
Thanks.
PS: Please Cc reply to me, cause I'm not subscribed.
--
Sergei "df" Kononov
GnuPG ID: 0x7D992F45
Linux - because software problems should not cost money. (by Shlomi Fish)
[-- Attachment #2: ptrace_trace_fork.c --]
[-- Type: text/x-csrc, Size: 3769 bytes --]
#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <linux/unistd.h>
#include <linux/ptrace.h>
#include <errno.h>
#include <string.h>
#define PTRACE_ALL PTRACE_O_TRACEFORK | PTRACE_O_TRACECLONE \
| PTRACE_O_TRACEVFORK | PTRACE_O_TRACEEXIT | \
PTRACE_O_TRACEEXEC | PTRACE_O_TRACESYSGOOD
#define PTRACE_FORK (PTRACE_O_TRACEFORK | PTRACE_O_TRACECLONE)
#define PTRACE_GENERIC (PTRACE_O_TRACEEXIT | PTRACE_O_TRACESYSGOOD)
#define SIGSYSTRAP (SIGTRAP | 0x80)
int ptrace_trace(pid_t pid, pid_t new)
{
struct user_regs_struct uregs, oregs;
long syscall, syscall_rval;
long *regs = 0;
int status, event, npid, not_exit = 1;
siginfo_t sigi;
if ( new )
{
ptrace(PTRACE_DETACH, pid, 0, 0);
wait(&status);
if ( WIFSTOPPED(status) && (WSTOPSIG(status) != SIGSTOP ))
{
printf("detach failed signal=%d\n", WSTOPSIG(status));
exit(1);
}
pid = new;
/* The next code is commented
* is process really detached? looks like no
* because of here I'll get EPERM, I suppose the problem is here:
* kernel/ptrace.c - ptrace_attach(task)
*/
/*
ptrace(PTRACE_ATTACH, new, 0, 0);
wait(&status);
if ( WIFSTOPPED(status) && (WSTOPSIG(status) != SIGSTOP ))
{
printf("attach failed signal=%d\n", WSTOPSIG(status));
exit(1);
}*/
ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_FORK | PTRACE_GENERIC | PTRACE_O_TRACEEXEC);
ptrace(PTRACE_CONT, pid, 0, 0);
}
while ( not_exit )
{
wait(&status);
if ( WIFSTOPPED(status) && (WSTOPSIG(status) == SIGSYSTRAP ||
WSTOPSIG(status) == SIGTRAP) )
{
ptrace(PTRACE_GETSIGINFO,pid,NULL,&sigi) ;
printf("siginfo=%d\n", sigi.si_code);
event = (sigi.si_code >> 8) & WSTOPSIG(status);
printf("status=%d,event=%d\n", status, event);
switch(event)
{
case PTRACE_EVENT_EXEC:
printf("exec\n");
break;
case PTRACE_EVENT_FORK:
case PTRACE_EVENT_VFORK:
case PTRACE_EVENT_CLONE:
ptrace(PTRACE_GETEVENTMSG, pid, NULL, &npid);
printf("fork|vfork|clone %d\n", npid);
printf("detaching from %d, attaching to %d\n", pid, npid);
ptrace_trace(pid, npid);
break;
case PTRACE_EVENT_EXIT:
printf("[%d] exit %d\n", npid, WEXITSTATUS(status));
not_exit = 0;
continue;
default:
printf("unknown event %d\n", event);
}
}
ptrace(PTRACE_CONT, pid, 0, WSTOPSIG(status));
}
}
int got_sig = 0;
void sigusr1(int d)
{
got_sig = 1;
}
int main(int argc, char **argv, char **env)
{
pid_t cp, pp;
int status;
signal(SIGUSR1, sigusr1);
pp = getpid();
cp = fork();
if ( cp == 0 )
{
ptrace(PTRACE_TRACEME, 0, 0, 0);
kill(pp, SIGUSR1);
while( ! got_sig );
execl(argv[1], argv[1], NULL);
}
else if ( cp > 0 )
{
printf("forkall=0x%x\n", PTRACE_ALL);
while( ! got_sig );
kill(cp, SIGUSR1);
wait(&status);
if ( ptrace(PTRACE_SETOPTIONS, cp, 0, \
PTRACE_FORK | PTRACE_GENERIC \
| PTRACE_O_TRACEEXEC ) == -1 && errno )
{
printf("ptrace(): %s\n", strerror(errno));
exit(1);
}
ptrace(PTRACE_CONT, cp, 0, WSTOPSIG(status));
ptrace_trace(cp, 0);
}
else
{
fprintf(stderr, "fork() failed\n");
}
return 0;
}
[-- Attachment #3: zdaemon.c --]
[-- Type: text/x-csrc, Size: 1298 bytes --]
#include <stdio.h>
#include <syslog.h>
#include <fcntl.h>
#include <sys/resource.h>
#include <signal.h>
#include <sys/stat.h>
#include <unistd.h>
void daemonize();
int main(int argc, char **argv)
{
daemonize();
while(1) {
sleep(5);
daemonize();
}
return 1;
}
void sig_handler(int signo)
{
return;
}
void daemonize()
{
struct sigaction term_sig; /* for SIGTERM, SIGINT, SIGHUP, SIGUSR1 and SIGUSR2 */
pid_t pid;
/* fork new child */
if ( (pid = fork()) > 0 )
{
exit(0); /* parent must die */
}
else if ( pid < 0 )
fprintf(stderr, "fork failed\n");
setsid(); /* new session started */
chdir("/"); /* our root is / */
close(STDIN_FILENO); /* close stdin */
close(STDERR_FILENO); /* close stderr and stdout if close_fd is 1 */
close(STDOUT_FILENO);
/* structs for signal handling */
memset(&term_sig, 0, sizeof(term_sig));
term_sig.sa_handler = &sig_handler; /* default signal handler function */
sigaction(SIGTERM, &term_sig, NULL);
sigaction(SIGINT, &term_sig, NULL);
sigaction(SIGHUP, &term_sig, NULL);
sigaction(SIGUSR1, &term_sig, NULL);
sigaction(SIGUSR2, &term_sig, NULL);
return;
}
^ permalink raw reply
* Re: [Desktop_printing] Re: [Printing-architecture] Re: Building PAPI implementation
From: Norm Jacobs @ 2006-05-18 19:02 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, desktop_printing@osdl.org
In-Reply-To: <446C92C3.8010008@gmx.net>
The SourceForge openprinting project PAPI implementation actually
contains multiple implementations of the PAPI, but the one that
you link with and interact with directly uses a "printer-uri-supported"
value in your name service/configuration data to contact the print
service for a particular print queue. If there isn't a
printer-uri-supported
in the configuration data, it doesn't know how to contact the print service
and will only return the name service/configuration data from a query. This
data is retrieved on Solaris using the name service switch and can be
stored in ${HOME}/.printers, /etc/printers.conf, NIS priners.conf.byname,
NIS+ printers.org_dir, and/or LDAP. On other platforms, the NSS support
is emulated and can be stored in /etc/printers.conf, /etc/printcap , and
NIS printers.conf.byname.
If you add a
"printer-uri-supported=ipp\://majax.mandrakesoft.com/printers/HPPSmart2600"
to the /etc/printers.conf or /etc/printcap entry for your printer, It's
likely
that you will see the results that you are looking for.
The PAPI implementation should probably be modified to use the "rm" and "rp"
information in abscense of a "printer-uri-supported" value. This would be
similiar to what is being done for "bsdaddr"
(see papi/source/libpapi-dynamic/nss.c:fill_printer_uri_supported)
Additionally, the cupsd code that generates /etc/printcap and
/etc/printers.conf
entries (cups/scheduler/printers.c:cupsWritePrintcap()) could be enhanced to
include the printer-uri-supported key/value data in it's output.
Finally, if you only plan on targeting a particular print service, you can
probably get away with removing libpapi.so and replacing it with a symlink
to psm-{svc}.so.
-Norm
PS
There are descriptions of the various bits in subversion under
papi/docs/README.*.
This is a short description of the PAPI implementations in the PAPI
code base.
I'll oversimplify this a little, but the PAPI implementation on SourceForge
contains multiple implementations of the PAPI (all exporting the PAPI
interface).
source/libpapi-dynamic (builds and installs as libpapi.so)
This implements something roughly analogous to the name service
switch. It is effectively interposed between the applications
and the "real" PAPI print service support. It resolves queue
names using a nameservice (/etc/printers.conf, /etc/printcap,
NIS printers.conf.byname). On Solaris this also includes
$HOME/.printers, NIS+ printers.org_dir, and LDAP. It uses the
"printer-uri-supported" information from these nameservices to
load backend PAPI print service support and contact the
real print service for the requested operation. The printer
query operations (papiPrintersList and papiPrintersQuery) support
in this library is "special" (and I don't necessarily mean that in
a good way), It may not contact the actual print service if the
name service contained the requested data.
source/libpapi-lpd (builds and installs as psm-lpd.so and lpd-port)
This implements support for contacting RFC-1179 based print
services.
Because of the limitted nature and wide variety of RFC-1179 support,
the PAPI support is very limitted. The following printer/job
operations do something useful:
papiPrinterQuery, papiPrinterPurgeJobs, papiPrinterListJobs,
papiJobSubmit, papiJobSubmitByReference,
papiJobStreamOpen/Write/Close,
papiJobQuery, papiJobCancel
Because RFC-1179 returns very little information, the query
functions return a very basic skeleton of information. They
could be made to provide information from an associated PPD file,
but there are other areas where the time might be better spent.
lpd-port provides a means of isolating parts of rfc-1179 support
that require elevated privilege from that application.
libpapi-ipp (builds and installs as psm-ipp.so)
This implements support for contacting IPP based print services. IPP
provides a a framework and rich set of operations and attributes for
printing. As a result, the PAPI support on top of IPP is complete.
It makes use of standard IPP operations and attributes for the vast
majority of the implementation with CUPS extensions being used where
there was no standard means.
Till Kamppeter wrote:
> I have probably found bugs in the PAPI library:
>
> I have CUPS 1.2.0 installed and the PAPI library. I have several local
> CUPS queues, one for an HP PhotoSmart 2600 using the HPIJS driver. With
> this driver I have the PPD options "PageSize", "PrintoutMode",
> "Quality", "InputSlot", and "Duplex". See
>
> http://www.linuxprinting.org/ppd-o-matic.cgi?driver=hpijs&printer=HP-PhotoSmart_2600&show=1
>
> for the PPD file. I can print on this printer using the PAPI "lpr "
> command and the printer is correctly shown with the PAPI "lpstat -p" and
> "lpstat -v".
>
> Now I run
>
> printer-query -d HPPSmart2600
>
> from the sample programs. According to its source code it is supposed to
> show all attributes of the printer when the command is called without
> the "-o" option (otherwise it wouls show only the specified attribute).
>
> What I get is
>
> --------------------------------------------------------------------------
> [root@majax c]# printer-query -d HPPSmart2600
> HPPSmart2600 at (default):
> printer-name=HPPSmart2600,HP Photosmart 2600
> rm=majax.mandrakesoft.com
> rp=HPPSmart2600
> [root@majax c]#
> --------------------------------------------------------------------------
>
> There came out only three attributes, "printer-name", "rp", and "rm".
> What I expect is (according to section 9 of the specs) attributes for
> each PPD option, and also some more attributes, like whether I have a
> color printer, which operations are supported and whatever the specs
> tell about required printer attributes.
>
> And if I take the name of one of the required attributes, as for example
> "operations-supported", I get the very same output as without supplying
> an attribute name:
>
> --------------------------------------------------------------------------
> [root@majax c]# printer-query -d HPPSmart2600 -ooperations-supported
> HPPSmart2600 at (default):
> printer-name=HPPSmart2600,HP Photosmart 2600
> rm=majax.mandrakesoft.com
> rp=HPPSmart2600
> [root@majax c]#
> --------------------------------------------------------------------------
>
> It seems that the query function
>
> --------------------------------------------------------------------------
> status = papiPrinterQuery(svc, destination, requested, NULL, &printer);
> --------------------------------------------------------------------------
>
> is not taking care of what is in "requested". Without "-o" option
> "requested" should be NULL and therefore all attributes should be
> returned in "printer", if "-o" is used "requested" should contain the
> argument of "-o" and therefore only this attribute should be shown (of
> an error if the attribute does not exist). See section 6 of the specs.
>
> The query (and the use) of the capabilities )section 9) of a CUPS queue
> (independent whether it is local or remote) is essential (all Linux
> systems use CUPS by default), as the user expects to be able to control
> duplex, finisher, quality, paper size, ... and so an ISV should be able
> to get these options into the printing dialog. If this is not possible,
> the current PAPI is not fully usable and cannot be suggested as a
> standard, as an ISV has to interface to CUPS (or to KDE) on Linux
> machines and to the OS-manufacturer-specific printing system on Sun
> machines (and so make two dialogs, which we want to avoid with proposing
> PAPI as a standard).
>
> Till
>
> Till Kamppeter wrote:
>
>> Now I got it working with CUPS by changing the default print service at
>> compile time. The problem was the quoting. The current code
>>
>> -----------------------------------------------------------------------
>> #ifndef DEFAULT_PRINT_SERVICE
>> #define DEFAULT_PRINT_SERVICE "lpsched"
>> #endif
>>
>> ...
>>
>> char *scheme = DEFAULT_PRINT_SERVICE;
>> -----------------------------------------------------------------------
>>
>> requires from the user to supply also the quotes. So in the spec file I
>> had to do
>>
>> -----------------------------------------------------------------------
>> export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=\\\"ipp\\\""
>> %configure --without-apache
>> %make
>> -----------------------------------------------------------------------
>>
>> Note the quoted quotes in the first line. This I did not do in the first
>> place and therefore it broke.
>>
>> But please still supply the documentation to configure PAPI at run time.
>> Also a possibility to define the compile time default by the configure
>> script, both by spooler auto discovery and also by command line option
>> would be great.
>>
>> Note also that on the linker call(s) for the Ruby bindings the
>>
>> -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs
>>
>> is missing. So I had to put
>>
>> -----------------------------------------------------------------------
>> export LDFLAGS="$LDFLAGS -L$RPM_BUILD_DIR/papi/source/libpapi-dynamic/.libs"
>> -----------------------------------------------------------------------
>>
>> before the "%configure" in the spec file.
>>
>> Till
>>
>>
>>
>> Till Kamppeter wrote:
>>
>>
>>> Now I got it RPMized so that it can be installed on a machine with
>>> already installed CUPS. No I tried to make it actually working with the
>>> installed CUPS. I found out by running an "lpr" command through strace
>>> that it tries to load the non-existing "lpsched" service
>>> (/usr/lib/psm-lpsched.so) and I have seen in the source code that
>>> "lpsched" is used a s the default service (should not be as "lpsched"
>>> does not ship with the package.
>>>
>>> So I compile with
>>>
>>> export CFLAGS="$CFLAGS -DDEFAULT_PRINT_SERVICE=ipp"
>>> ./configure --without-apache --without-ruby
>>> make
>>>
>>> to make it using "ipp" as default service (can one configure/switch the
>>> service at run time? There are no files in /etc/... and no documentation
>>> about such files, man pages are only in section 1 and 8, nothing in
>>> section 5).
>>>
>>> But with this setting it does not build:
>>>
>>> ------------------------------------------------------------------------------------
>>> [...]
>>> Making all in libpapi-dynamic
>>> make[2]: Entering directory
>>> `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic'
>>> if /bin/sh ../../libtool --tag=CC --mode=compile
>>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\"
>>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1
>>> -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF ".deps/psm.Tpo" -c -o
>>> psm.lo psm.c; \
>>> then mv -f ".deps/psm.Tpo" ".deps/psm.Plo"; else rm -f ".deps/psm.Tpo";
>>> exit 1; fi
>>> mkdir .libs
>>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\"
>>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1
>>> -DDEFAULT_PRINT_SERVICE=ipp -MT psm.lo -MD -MP -MF .deps/psm.Tpo -c
>>> psm.c -fPIC -DPIC -o .libs/psm.o
>>> if /bin/sh ../../libtool --tag=CC --mode=compile
>>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\"
>>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1
>>> -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF
>>> ".deps/service.Tpo" -c -o service.lo service.c; \
>>> then mv -f ".deps/service.Tpo" ".deps/service.Plo"; else rm -f
>>> ".deps/service.Tpo"; exit 1; fi
>>> i586-mandriva-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../../source/libpapi-common -I. -DPSM_DIR=\"/usr/lib\"
>>> -I../libpapi-common -I./nss -DNSS_EMULATION -I/usr/include/apr-1
>>> -DDEFAULT_PRINT_SERVICE=ipp -MT service.lo -MD -MP -MF .deps/service.Tpo
>>> -c service.c -fPIC -DPIC -o .libs/service.o
>>> service.c: In function 'service_load':
>>> service.c:60: error: 'ipp' undeclared (first use in this function)
>>> service.c:60: error: (Each undeclared identifier is reported only once
>>> service.c:60: error: for each function it appears in.)
>>> ICECREAM[19319]: Compiled on 192.168.2.67
>>> make[2]: *** [service.lo] Error 1
>>> make[2]: Leaving directory
>>> `/home/tkamppeter/rpm/BUILD/papi/source/libpapi-dynamic'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/papi/source'
>>> make: *** [all-recursive] Error 1
>>> ------------------------------------------------------------------------------------
>>>
>>> Can you tell me how to get it correctly talking with CUPS? Thanks.
>>>
>>> Till
>>>
>>>
>>
>
> _______________________________________________
> Desktop_printing mailing list
> Desktop_printing@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/desktop_printing
>
^ permalink raw reply
* Re: auditctl usage for filter lists: "user" , "watch" and "exclude"
From: Michael C Thompson @ 2006-05-18 19:01 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <200605181216.20424.sgrubb@redhat.com>
Steve Grubb wrote:
> On Thursday 18 May 2006 12:04, Michael C Thompson wrote:
>> So then it should be safe to say that having two -F msgtype=... is an
>> invalid construct for a rule? Since messages have only 1 type?
>
> Only if they are using the '=' operator. Other operators might be valid to
> have multiple -F msgtype.
Ah yes, good point. I'll be sure to properly test the relational
operators. Other than the source code, is there any place for a user to
go and get the message types to determine their ordering?
Mike
^ permalink raw reply
* Re: 2.6.16 + reiser4 -2 patch = gcc error
From: Tom Vier @ 2006-05-18 19:01 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: reiserfs-list
In-Reply-To: <1147945452.6417.24.camel@tribesman.namesys.com>
On Thu, May 18, 2006 at 01:44:12PM +0400, Vladimir V. Saveliev wrote:
> I guess you got broken lines 485 and 507 in file
> fs/reiser4/plugin/file_ops_readdir.c
>
> Here is what you should have:
> 485: mutex_lock(&inode->i_mutex);
> 507: mutex_unlock(&inode->i_mutex);
Actually, it was my fault. I had forgotten to apply the 2.6.15->.16 patch.
Thanks for you help, tho.
--
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE
^ permalink raw reply
* [PATCH] sector_t overflow in block layer
From: Andreas Dilger @ 2006-05-18 18:59 UTC (permalink / raw)
To: Stephen C. Tweedie
Cc: ext2-devel@lists.sourceforge.net, Andrew Morton, Linus Torvalds,
linux-kernel
In-Reply-To: <1147947803.5464.19.camel@sisko.sctweedie.blueyonder.co.uk>
On May 18, 2006 11:23 +0100, Stephen C. Tweedie wrote:
> On Wed, 2006-05-17 at 17:58 -0600, Andreas Dilger wrote:
> > > the next question then is should we fail mounting of any >2TB fs
> > > w/o CONFIG_LBD or it would be better to mount IFF the fs has
> > > no allocated blocks beyond 2TB?
> >
> > This could actually be the primary source of the > 2TB filesystem
> > corruption problem that I've seen reported occasionally. The question
> > is if CONFIG_LBD isn't enabled will the kernel silently truncate
> > block-layer offsets?
>
> It appears so, yes. bread() goes through submit_bh(), which converts
> blocknr to sector with:
>
> bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
>
> without checking for overflow.
>
> > This would seem to be a critical kernel bug that should be addressed in
> > the block subsystem to prevent use of block devices > 2TB if sector_t
> > is only 32 bits.
>
> I think the arguments are a little less strong about restricting block
> device access in such cases, but certainly filesystem access needs to be
> properly checked. We need to check the *filesystem* size, not the
> device size (they are usually the same but they don't strictly have to
> be), both on mount and on attempted resize.
At least the submit_bh() code should return an error in this case
regardless of who the caller is. If ext[23] and other filesystems
check this themselves at mount time that is of course also prudent.
Patch has not been more than compile tested but it is a pretty serious
problem dating back a long time so I'm posting it for review anyways.
There are several ways to check for the 64-bit overflow, the efficiency
of which depends on the architecture. We could alternately shift b_blocknr
by >> 41 or change the mask, for example. The primary concern is really
the 32-bit overflow and resulting silent and massive data corruption
when CONFIG_LBD isn't enabled.
It is coincidental that mke2fs will clobber the primary group's metadata
(bitmaps, inode table) when formatting such a filesystem, but since this
data is identical at format time (group 0 offsets and group 16384 offsets
modulo 2TB are the same) it is very hard to detect before corruption hits.
==================== buffer_overflow.diff ===============================
--- ./fs/buffer.c.orig 2006-05-18 12:15:45.000000000 -0600
+++ ./fs/buffer.c 2006-05-18 12:09:20.000000000 -0600
@@ -2758,12 +2784,32 @@ static int end_bio_bh_io_sync(struct bio
int submit_bh(int rw, struct buffer_head * bh)
{
struct bio *bio;
+ unsigned long long sector;
int ret = 0;
BUG_ON(!buffer_locked(bh));
BUG_ON(!buffer_mapped(bh));
BUG_ON(!bh->b_end_io);
+ /* Check if we overflow sector_t when computing the sector offset. */
+ sector = (unsigned long long)bh->b_blocknr * (bh->b_size >> 9);
+#if !defined(CONFIG_LBD) && BITS_PER_LONG == 32
+ if (unlikely(sector != (sector_t)sector))
+#else
+ if (unlikely(((bh->b_blocknr >> 32) * (bh->b_size >> 9)) >=
+ 0xffffffff00000000ULL))
+#endif
+ {
+ printk(KERN_ERR "IO past maximum addressable sector"
+#if !defined(CONFIG_LBD) && BITS_PER_LONG == 32
+ "- CONFIG_LBD not enabled"
+#endif
+ "\n");
+ buffer_io_error(bh);
+
+ return -EOVERFLOW;
+ }
+
if (buffer_ordered(bh) && (rw == WRITE))
rw = WRITE_BARRIER;
@@ -2780,7 +2828,7 @@ int submit_bh(int rw, struct buffer_head
*/
bio = bio_alloc(GFP_NOIO, 1);
- bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
+ bio->bi_sector = sector;
bio->bi_bdev = bh->b_bdev;
bio->bi_io_vec[0].bv_page = bh->b_page;
bio->bi_io_vec[0].bv_len = bh->b_size;
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
^ permalink raw reply
* Re: replacing X Window System !
From: Thierry Vignaud @ 2006-05-18 18:52 UTC (permalink / raw)
To: linux cbon; +Cc: Helge Hafting, Valdis.Kletnieks, linux-kernel
In-Reply-To: <20060518172827.73908.qmail@web26601.mail.ukl.yahoo.com>
linux cbon <linuxcbon@yahoo.fr> writes:
> Why dont we have "good" 3D support in X ?
no documentation how to program nvidia 3d chips?
or for the very latest ati chips?
or from the XYZ vendor?
....
> > Also, please tell why this would be faster, simpler, or easier to
> > manage. Stuff in the kernel is generally harder to manage than
> > userspace stuff, and definitely not simpler. Kernel code lives
> > with all sorts of requirements and limitations that an application
> > programmer would hate to have to worry about.
>
> Put X in the kernel, so we dont have 7924 bad written
> incompatible implementations of it.
no, we now have 7924 kernels that have to implement each of these
drivers (linux, *bsd, other unices, macos x, ...)
ow! how do we do with macos x? or on windows?
no more X? (though i don't really care but...)
> In my opinion, graphics do belong to the OS, like
> sound, network and file system.
"belong to the OS" != "belong in the kernel"
and where do you put the boundary of the OS? most people don't say
that the OS is only the kernel...
>
> How to improve/replace X :
> http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/
> http://www.doc.ic.ac.uk/teaching/projects/Distinguished03/MarkThomas.pdf
like if xorg wasn't trying to improve x11 status (slowly trying to
isolate priviliged stuff, introducing xcb, ...)
> What is your opinion ?
stop troll^h^h^h^h^h thread?
^ permalink raw reply
* [PATCH] - make qemu serial summagraphics settings a bit more fluid
From: Ben Thomas @ 2006-05-18 18:50 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
Changeset 9967 made the qemu serial line Summagraphics support a little
more flexible with respect to the COM line chosen. This patch
furthers that effort by removing the COM2 restriction. This patch
allows a "-summa n" command line option to qemu to specify which, if
any, COM port should be using the Summagraphics protocols.
Signed-off-by: Ben Thomas (ben@virtualiron.com)
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
[-- Attachment #2: summa.patch --]
[-- Type: text/x-patch, Size: 3672 bytes --]
diff -r 48c0f5489d44 tools/ioemu/hw/pc.c
--- a/tools/ioemu/hw/pc.c Thu May 18 11:39:03 2006 +0100
+++ b/tools/ioemu/hw/pc.c Thu May 18 14:46:20 2006 -0400
@@ -537,7 +537,7 @@ void pc_init(uint64_t ram_size, int vga_
for(i = 0; i < MAX_SERIAL_PORTS; i++) {
if (serial_hds[i]) {
sp = serial_init(serial_io[i], serial_irq[i], serial_hds[i]);
- if (i == SUMMA_PORT)
+ if (serial_summa[i])
summa_init(sp, serial_hds[i]);
}
}
diff -r 48c0f5489d44 tools/ioemu/vl.c
--- a/tools/ioemu/vl.c Thu May 18 11:39:03 2006 +0100
+++ b/tools/ioemu/vl.c Thu May 18 14:46:20 2006 -0400
@@ -146,6 +146,7 @@ int repeat_key = 1;
int repeat_key = 1;
TextConsole *vga_console;
CharDriverState *serial_hds[MAX_SERIAL_PORTS];
+int serial_summa[MAX_SERIAL_PORTS];
int xc_handle;
time_t timeoffset = 0;
@@ -2244,6 +2245,7 @@ void help(void)
"Debug/Expert options:\n"
"-monitor dev redirect the monitor to char device 'dev'\n"
"-serial dev redirect the serial port to char device 'dev'\n"
+ "-summa n set serial line COMn to be a Summagraphics tablet"
"-S freeze CPU at startup (use 'c' to start execution)\n"
"-s wait gdb connection to port %d\n"
"-p port ioreq port for xen\n"
@@ -2349,6 +2351,7 @@ enum {
QEMU_OPTION_monitor,
QEMU_OPTION_domainname,
QEMU_OPTION_serial,
+ QEMU_OPTION_summa,
QEMU_OPTION_timeoffset,
QEMU_OPTION_loadvm,
QEMU_OPTION_full_screen,
@@ -2425,6 +2428,7 @@ const QEMUOption qemu_options[] = {
{ "domain-name", 1, QEMU_OPTION_domainname },
{ "timeoffset", HAS_ARG, QEMU_OPTION_timeoffset },
{ "serial", 1, QEMU_OPTION_serial },
+ { "summa", 1, QEMU_OPTION_summa },
{ "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
{ "full-screen", 0, QEMU_OPTION_full_screen },
@@ -2554,6 +2558,7 @@ int main(int argc, char **argv)
char monitor_device[128];
char serial_devices[MAX_SERIAL_PORTS][128];
int serial_device_index;
+ int summa_index;
char qemu_dm_logfilename[64];
const char *loadvm = NULL;
unsigned long nr_pages, *page_array;
@@ -2588,9 +2593,11 @@ int main(int argc, char **argv)
pstrcpy(monitor_device, sizeof(monitor_device), "vc");
pstrcpy(serial_devices[0], sizeof(serial_devices[0]), "vc");
- pstrcpy(serial_devices[1], sizeof(serial_devices[1]), "null");
- for(i = 2; i < MAX_SERIAL_PORTS; i++)
+ serial_summa[0] = 0;
+ for(i = 1; i < MAX_SERIAL_PORTS; i++) {
serial_devices[i][0] = '\0';
+ serial_summa[i] = 0;
+ }
serial_device_index = 0;
nb_tun_fds = 0;
@@ -2931,6 +2938,15 @@ int main(int argc, char **argv)
sizeof(serial_devices[0]), optarg);
serial_device_index++;
break;
+ case QEMU_OPTION_summa:
+ summa_index = atoi(optarg);
+ if ( (summa_index <= 0) || (summa_index > MAX_SERIAL_PORTS) ) {
+ fprintf(stderr, "qemu: summa index out of range\n");
+ exit(1);
+ }
+ serial_summa[i-1] = 1;
+ break;
+
case QEMU_OPTION_loadvm:
loadvm = optarg;
break;
diff -r 48c0f5489d44 tools/ioemu/vl.h
--- a/tools/ioemu/vl.h Thu May 18 11:39:03 2006 +0100
+++ b/tools/ioemu/vl.h Thu May 18 14:46:20 2006 -0400
@@ -238,9 +238,9 @@ void console_select(unsigned int index);
/* serial ports */
#define MAX_SERIAL_PORTS 4
-#define SUMMA_PORT 1
extern CharDriverState *serial_hds[MAX_SERIAL_PORTS];
+extern serial_summa[MAX_SERIAL_PORTS];
/* network redirectors support */
[-- Attachment #3: 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: Fix time going backward with clock=pit [1/2]
From: Tim Mann @ 2006-05-18 18:50 UTC (permalink / raw)
To: Roman Zippel; +Cc: mann, linux-kernel, john stultz
In-Reply-To: <Pine.LNX.4.64.0605181249020.17704@scrub.home>
On Thu, 18 May 2006 13:51:36 +0200 (CEST), Roman Zippel <zippel@linux-m68k.org> wrote:
> Hi,
>
> On Wed, 17 May 2006, Tim Mann wrote:
>
> > 2) do_timer_overflow was trying to detect the case where the counter
> > has wrapped since jiffies was incremented by checking whether the
> > timer interrupt is still pending in the PIC. This is bogus for a
> > couple of reasons: (a) There is a window between the point where
> > the PIC interrupt is acknowledged and jiffies is incremented.
> > (b) Most systems use the IOAPIC for interrupt routing now. The
> > kernel has code that tries to also route the timer interrupt to the
> > PIC and acknowledge it there, but this does not appear to work; in
> > my testing on a couple of IOAPIC systems, do_timer_overflow always
> > thought a timer interrupt was pending. Also, this code has the
> > same window as in (a).
>
> Do you (or anyone else) have more information about this? If it's not
> possible to detect the underflow,
I don't know of a reliable way to detect when we're in the state that
the PIT has wrapped but the resulting interrupt hasn't yet been handled
far enough to cause jiffies to be incremented. I doubt there is one.
Here are two ideas that work in other roughly-similar cases but not here:
1) Generally, on counters that don't interrupt when they wrap, you can
watch for the high-order bit to toggle and detect the wrap that way, and
that method doesn't require handling an interrupt atomically with
reading the counter. However, this is only reliable if you can be
certain to read the counter often enough to detect all the wraps, which
isn't the case with the PIT counter -- it wraps way too often.
2) There are algorithms for reading multi-word hardware counters that
increment atomically but can't be read atomically; for example:
high1 = <read high word of counter>;
do {
high2 = high1;
low = <read low word of counter>;
high1 = high2;
} while (high1 != high2);
... but that doesn't work either, because there still could be a pending
PIT timer interrupt that was routed to another CPU and not handled yet.
The unpredictable delay between the PIT wrapping and jiffies getting
incremented is a killer.
> it would mean that PIT isn't usable
> as clock in these cases, as the clock would still jump around (just not
> visibly backwards).
Yeah, the PIT counter is still not a very good clock source. It's
better on average than just returning the jiffy count, but in the worst
case you can still get a time that's old by up to almost a jiffy (using
the code I sent, and I don't see how to do better).
> > if( jiffies_t == jiffies_p ) {
> > if( count > count_p ) {
> > /* the nutcase */
> > - count = do_timer_overflow(count);
> > + count = count_p;
> > }
> > } else
> > jiffies_p = jiffies_t;
>
> IMO the else part is not correct.
The else part is correct if we eliminate the possibility that jiffies
gets incremented between reading count and reading jiffies (by reading
jiffies first). It looks like you're trying to solve that problem
without moving the read of jiffies above count, but your code is too
sketchy. Also, I don't really see why you want to do that.
> I think the whole think should look
> something like this:
>
> if (jiffies_t == jiffies_p) {
> if (count > count_p) {
> underflow or crappy timer;
What should the code do in this case?
> }
> } else {
> jiffies_p = jiffies_t;
> if (count > LATCH/2 && underflow)
> count -= LATCH;
I think I see what you're aiming at here: in the case where we read
count, then the counter wraps, then we read jiffies, you want to detect
that and fix it. Actually if you could detect that, the right way to
fix it would be to set count = LATCH, since the old count is, well, old:
the current time is right after the jiffy.
However, we don't really have a way to detect that this case happened --
the "&& underflow" in your code is a handwave.
> }
>
> This would also basically solve the ordering problem, retrying the
> function would produce the correct result.
>
> So we basically have two issues:
> 1. Fix the timekeeping to produce correct results.
> 2. Broken underflow handling.
>
> If the second isn't fixable, it would make the whole thing practically
> unusable. I hope that it's at least detectable, so we don't use it as a
> clock, which would be IMO preferable instead of completely removing the
> underflow check (which would make the clock unreliable for everyone).
>
> BTW another bug here is the wrong initialization of jiffies_p (it should
> be INITIAL_JIFFIES).
>
> bye, Roman
--
Tim Mann work: mann@vmware.com home: tim@tim-mann.org
http://www.vmware.com http://tim-mann.org
^ 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.