All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 17:41 UTC (permalink / raw)
  To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007172939.GA12130@sigill.intra.peff.net>

On Thu, Oct 7, 2010 at 7:29 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 07:18:18PM +0400, Kirill Likhodedov wrote:
>
>> Thanks for pointing that out.
>> I confirm that on Mac OS X that happens for rev-list as well.
>>
>> # git log --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000   f   o   o  \0   b   a   r
>> 0000007
>>
>> # git rev-list --pretty=format:foo%x00bar HEAD -1 | od -c
>> 0000000   c   o   m   m   i   t       2   3   6   0   1   a   2   c   3
>> 0000020   e   4   6   4   a   4   4   7   9   f   1   7   7   4   e   3
>> 0000040   6   e   a   5   b   9   5   8   b   4   6   0   5   2   1  \n
>> 0000060   f   o   o  \n
>> 0000064
>
> Ugh. Even worse, it does print with --graph, which uses a slightly
> different code path.
>
>  $ git rev-list --graph -1 --format=foo%x00bar HEAD | cat -A
>  *   commit 81d866a6a213d5524ce389369377ba3529461e1b$
>  |\  foo^@bar$
>
> I am inclined to call the rev-list behavior a bug, and the fix is
> probably:
>
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index efe9360..3b2dca0 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
>                        }
>                } else {
>                        if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> -                           buf.len)
> -                               printf("%s%c", buf.buf, info->hdr_termination);
> +                           buf.len) {
> +                               fwrite(buf.buf, 1, buf.len, stdout);
> +                               putchar(info->hdr_termination);
> +                       }
>                }
>                strbuf_release(&buf);
>        } else {

This gives me a bit of a deja-vu: 1fb5fdd

Also, fwriting like that to stdout might be a bit troublesome on
Windows because the string won't end up going through our
ANSI-emulation.

^ permalink raw reply

* Re: git log doesn't allow %x00 in custom format anymore?
From: Matthieu Moy @ 2010-10-07 17:40 UTC (permalink / raw)
  To: Jeff King; +Cc: Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007172939.GA12130@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index efe9360..3b2dca0 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
>  			}
>  		} else {
>  			if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> -			    buf.len)
> -				printf("%s%c", buf.buf, info->hdr_termination);
> +			    buf.len) {
> +				fwrite(buf.buf, 1, buf.len, stdout);
> +				putchar(info->hdr_termination);
> +			}
>  		}
>  		strbuf_release(&buf);
>  	} else {

Sounds like a sane thing to do, yes.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply

* Re: Git over SMBFS
From: Casey Dahlin @ 2010-10-07 17:40 UTC (permalink / raw)
  To: fREW Schmidt; +Cc: git
In-Reply-To: <AANLkTik9U_jr6r6BuUcRrk8pjQTacKDY7YbqWnfrCLmD@mail.gmail.com>

On Tue, Oct 05, 2010 at 09:26:15PM -0500, fREW Schmidt wrote:
> A coworker of mine is working on a project that is running on a
> windows server.  The project is in git, but we are having a lot of
> trouble getting it to work at all.  For example, if he merely does
> (from his machine) "git checkout ." it seemingly times out after 680
> files being checked out.
> 
> Are there any settings we might be able to tweak that might make git
> more tolerable of the latency involved in a network based checkout?
> 

Sounds to me like the best way would be to make a local copy with

git clone /path/to/cifs/mounted/project

And then do your work on the local hard disk. Later, you can git-push
back in to the cifs folder.

--CJD

^ permalink raw reply

* [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
From: Vimal Singh @ 2010-10-07 17:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1285063280-4057-10-git-send-email-manjugk@ti.com>

On Tue, Sep 21, 2010 at 3:31 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> Following sparse warnings exists due to use of writel/w and readl/w functions.
>
> This patch fixes the sparse warnings by converting readl/w functions usage into
> __raw_readl/__raw_readw functions.
>
[...]
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -481,7 +481,7 @@ static int omap_verify_buf(struct mtd_info *mtd, const u_char * buf, int len)
>
> ? ? ? ?len >>= 1;
> ? ? ? ?while (len--) {
> - ? ? ? ? ? ? ? if (*p++ != cpu_to_le16(readw(info->nand.IO_ADDR_R)))
> + ? ? ? ? ? ? ? if (*p++ != cpu_to_le16(__raw_readw(info->nand.IO_ADDR_R)))

There was an old comment to remove use of 'cpu_to_le16' from driver, I
just missed it. Can you rather use 'ioread16_rep' for reading data.

-- 
Regards,
Vimal Singh

^ permalink raw reply

* Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
From: Vimal Singh @ 2010-10-07 17:39 UTC (permalink / raw)
  To: G, Manjunath Kondaiah; +Cc: linux-omap, linux-mtd, linux-arm-kernel
In-Reply-To: <1285063280-4057-10-git-send-email-manjugk@ti.com>

On Tue, Sep 21, 2010 at 3:31 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> Following sparse warnings exists due to use of writel/w and readl/w functions.
>
> This patch fixes the sparse warnings by converting readl/w functions usage into
> __raw_readl/__raw_readw functions.
>
[...]
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -481,7 +481,7 @@ static int omap_verify_buf(struct mtd_info *mtd, const u_char * buf, int len)
>
>        len >>= 1;
>        while (len--) {
> -               if (*p++ != cpu_to_le16(readw(info->nand.IO_ADDR_R)))
> +               if (*p++ != cpu_to_le16(__raw_readw(info->nand.IO_ADDR_R)))

There was an old comment to remove use of 'cpu_to_le16' from driver, I
just missed it. Can you rather use 'ioread16_rep' for reading data.

-- 
Regards,
Vimal Singh

^ permalink raw reply

* Re: [linux-lvm] Grub with UUID
From: Ray Morris @ 2010-10-07 17:38 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <AANLkTikzS14BL5PkbLm12_555khqLYGmDaDY+hV8gz2a@mail.gmail.com>

> I wanted to use GRUB with UUID when i pass the
> boot flags root=. When i did this, my system cannot mount the root
> more.

root= is not a grub argument, it's a kernel argument.
If it's wrong, you'll get a few dozen lines of output and then
it'll say "can not mount root filesystem" or something similar.

root (hd0,0) would be grub.  If it's wrong, you'll get less than
a dozen lines of output before the error message.

Try mounting first with root=/dev/sda2 or whatever, then double
check a) the UUID and b) the syntax you're using, which should be
something like:
root=UUID=xxx

If the root volume isn't a plain disk partition, but is rather
a logical voume or mdadm, your initrd will need to include lvm,
raid, or whatever else is needed to get the root volume up and
running.

See also super grub disk, which can be helpful for figuring all
of this stuff out.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 10/07/2010 12:12:56 PM, Fabricio Archanjo wrote:
> Hey all,
> 
> 
> Sorry because my stupid question, but i don't know more. I'm using
> Debian with LVM and I wanted to use GRUB with UUID when i pass the
> boot flags root=. When i did this, my system cannot mount the root
> more. May someone know why it happend? is there a problem with GRUB
> v1??
> 
> 
> Thanks all,
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 
> 

^ permalink raw reply

* Creating the Agenda for OEDEM 2010
From: Holger Freyther @ 2010-10-07 17:38 UTC (permalink / raw)
  To: openembedded-devel

Hi All,

the OEDEM 2010 in Cambridge on the 29th and 30th is approaching fast and we
should start creating the Agenda. We already have a wikipage here[1] and I
would encourage to collect topics there and start building an agenda before
event to be as effective as possible.

thanks
	z.

[1] http://wiki.openembedded.org/index.php/Oedem/2010



^ permalink raw reply

* Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
From: David Nicol @ 2010-10-07 17:38 UTC (permalink / raw)
  Cc: linux-btrfs
In-Reply-To: <201010070810.42505.kreijack@libero.it>

On Thu, Oct 7, 2010 at 1:10 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:
> Please the next time put your patch inline or it is more difficult to
> highlight a suggestion.

* drop support for years and months, except as identified usage errors

* lower-case 'm' now minutes

* escalate syntax warnings to fatal exits


diff --git a/iso8601toms.c b/iso8601toms.c
index a1ee9bd..f982d34 100644
--- a/iso8601toms.c
+++ b/iso8601toms.c
@@ -25,6 +25,8 @@

     accept a non-integer as the last numeric component

+    always treats "m" as minutes
+
  it silently accepts:

     out of order duration type letters
@@ -35,10 +37,12 @@

     non-integers in any position

- it warns on:
+ it halts and catches fire on:

     P or p appearing somewhere besides the beginning of the string

+    Attempts to use Years or Months
+
     unrecognized characters


@@ -53,7 +57,6 @@ unsigned long iso8601toms(char *P){
     char *ptr;
     char *endptr;
     short M_min = 0;
-
     ms = 0UL;
     ptr = P;
     for(;;){
@@ -62,18 +65,13 @@ unsigned long iso8601toms(char *P){
        {
           case 'P': /* anchor */ case 'p':
              if (ptr > P)
-                fprintf(stderr, "ignoring non-initial P "
-                         "in ISO8601 duration string %s\n", P);
-             break;
-          case 'Y': /* years */ case 'y':
-             component *= 12;
-          BIGM:
-             /* average days in a gregorian month */
-             component *= (365.2425 / 12.0);
-             /* ms in a day */
-             component *= ( 24 * 3600 * 1000 );
-             ms += component;
-             break;
+                fprintf(stderr, "non-initial P "
+                         "in duration string %s\n", P);
+                 exit (-1);
+          case 'Y': /* year */ case 'y':
+                fprintf(stderr, "Years are not supported "
+                         "in duration string %s\n", P);
+                 exit (-1);
           case 'T': /* Time (not date) anchor */ case 't':
              M_min = 1;
              break;
@@ -84,9 +82,15 @@ unsigned long iso8601toms(char *P){
           case 'H': /* hour */ case 'h':
              component *= 60;
              M_min = 1;
-          case 'M': /* month, or minute */ case 'm':
-             if (!M_min++)
-                 goto BIGM;
+          case 'M': /* month, or minute */
+             if (M_min == 0 ){
+                fprintf(stderr, "Months are not supported "
+                         "in duration string %s\n"
+                         "use 'm' instead or prefix a 'T'\n"
+                         , P);
+                 exit (-1);
+             };
+          case 'm': /* minute */
              component *= 60;
           case 'S': /* second */ case 's':
           case '\0': /* default to second */
@@ -96,10 +100,11 @@ unsigned long iso8601toms(char *P){

           default:
             fprintf(stderr,
-                "ignoring unexpected char [%c] "
-                "in iso8601 duration string %s\n",
+                "unexpected char [%c] in duration string %s\n"
+                "valid designators are [WwDdHhMmSs] with implied
trailing S.\n",
                 *endptr, P
              );
+             exit (-1);
        };
        if (!*endptr)
           return (ms);

^ permalink raw reply related

* [Bug 30684] New: r300g: OpenVG demos fail to render properly
From: bugzilla-daemon @ 2010-10-07 17:37 UTC (permalink / raw)
  To: dri-devel

https://bugs.freedesktop.org/show_bug.cgi?id=30684

           Summary: r300g: OpenVG demos fail to render properly
           Product: Mesa
           Version: git
          Platform: All
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r300
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: virtuousfox@gmail.com


lion_x11: all i see is counterclockwise rotating black figure which stops if i
move the window and then start rotating again. it disappears if i maximize
window to fullscreen.
sp_x11: just a black figure on white background.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply

* [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
From: Kevin Hilman @ 2010-10-07 17:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20100928233334.GS21564@trinity.fluff.org>

Ben Dooks <ben-i2c@fluff.org> writes:

[...]

> As such, I should really go and read up all about this new runtime-pm
> and hwmod stuff before further commentign on the changes.

ping


>From bogus@does.not.exist.com  Wed Oct  6 18:52:23 2010
From: bogus@does.not.exist.com ()
Date: Wed, 06 Oct 2010 22:52:23 -0000
Subject: No subject
Message-ID: <mailman.2.1286473034.390.linux-arm-kernel@lists.infradead.org>

omap_hwmod.  You can think of this change as simply using the runtime PM
API instead of the clock API for enabling and idling the device.

With your ack (on this patch only) we'd like to merge this along with
the rest of the series for 2.6.37.

Kevin

^ permalink raw reply

* Re: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
From: Kevin Hilman @ 2010-10-07 17:37 UTC (permalink / raw)
  To: Ben Dooks
  Cc: Nayak, Rajendra, Paul Walmsley, linux-i2c@vger.kernel.org,
	ben-linux@fluff.org, khali@linux-fr.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100928233334.GS21564-SMNkleLxa3Z6Wcw2j4pizdi2O/JbrIOy@public.gmane.org>

Ben Dooks <ben-i2c-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org> writes:

[...]

> As such, I should really go and read up all about this new runtime-pm
> and hwmod stuff before further commentign on the changes.

ping

>From the drivers perspective, you don't neet to know anything about
omap_hwmod.  You can think of this change as simply using the runtime PM
API instead of the clock API for enabling and idling the device.

With your ack (on this patch only) we'd like to merge this along with
the rest of the series for 2.6.37.

Kevin

^ permalink raw reply

* Re: [Qemu-devel] Re: [PATCH 09/11] i386: avoid a write only variable
From: Blue Swirl @ 2010-10-07 17:36 UTC (permalink / raw)
  To: malc; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <alpine.LNX.2.00.1010071225170.1817@linmac>

On Thu, Oct 7, 2010 at 8:27 AM, malc <av1474@comtv.ru> wrote:
> On Thu, 7 Oct 2010, Paolo Bonzini wrote:
>
>> On 10/06/2010 11:34 PM, Blue Swirl wrote:
>> > Compiling with GCC 4.6.0 20100925 produced warnings:
>> > /src/qemu/target-i386/op_helper.c: In function 'switch_tss':
>> > /src/qemu/target-i386/op_helper.c:283:53: error: variable 'new_trap'
>> > set but not used [-Werror=unused-but-set-variable]
>> >
>> > Fix by deleting the variable.
>>
>> Again, this warning tells us the emulation is incorrect, so it's wrong to
>> remove it.
>>
>
> http://support.amd.com/us/Processor_TechDocs/24593.pdf
>
> 12.2.5
> T (Trap) Bit--■Bit 0 of byte 64h, static field. This bit, when set to1,
> causes a debug exception (#DB) to occur on a task switch. See "Beakpoint
> Instruction (INT3)" page 340 for additional information.

Yes, I read that before making the patch. But page 340 didn't seem to
give any relevant information.

^ permalink raw reply

* Re: pvops Dom0 graphics doesnt work with Intel i915
From: sanjay kushwaha @ 2010-10-07 17:36 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk; +Cc: Jeremy Fitzhardinge, xen-devel
In-Reply-To: <20101007010729.GA22018@dumpdata.com>


[-- Attachment #1.1: Type: text/plain, Size: 8891 bytes --]

Hi Konrad,
I tried your tree. It created a 2.6.32.15 based pvops kernel but graphics
with VT-d still doesn't work. when I give iommu=0 on xen kernel command line
in grub menu, graphics works but with iommu=1 it doesnt work (The whole
screen is garbage).


On Wed, Oct 6, 2010 at 6:07 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Wed, Oct 06, 2010 at 04:02:51PM -0700, sanjay kushwaha wrote:
> > Thanks Pasi.
> >
> > Hi Konrad,
> > Could you please let me know how to get these backported drivers as
> > indicated by Pasi? This is the tree that I have.
>
> Just follow the Wiki. Oh, I need to update it.
>
> Here do this:
>
> git remote add konrad  git://
> git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>
> git pull konrad
> git checkout konrad/devel/next.drm
>
> make
>
> >
> > [evans@vwifi0 linux-2.6.32.x]$ git show
> > commit b297cdac0373625d3cd0e6f2b393570dcf2edba6
> > Merge: c6cfd01 64392f6
> > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > Date:   Mon Sep 13 14:27:24 2010 -0700
> >
> >     Merge branch 'xen/next' into xen/next-2.6.32
> >
> >     * xen/next:
> >       xen/netfront: Fix another potential race condition
> >       Revert "xen/netfront: default smartpoll to on"
> >
> > [evans@vwifi0 linux-2.6.32.x]$
> >
> >
> > Thanks,
> > Sanjay
> >
> > On Wed, Oct 6, 2010 at 1:12 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >
> > > On Wed, Oct 06, 2010 at 10:50:57AM -0700, sanjay kushwaha wrote:
> > > >    Hi,
> > > >    I have run into more problems now. This time with VT-d.
> > > >    When I enable VT-d on this laptop, graphics again stops working in
> > > dom0
> > > >    with pvops (linux 2.6.32.21). the screen starts showing garbage as
> > > soon as
> > > >    it switches into graphics mode.this happens when I boot the pvops
> > > kernel
> > > >    both as dom0 and native linux. However, when I try 2.6.33 based
> pvops
> > > >    kernel (stable-2.6.33.x) graphics seems to work fine with VT-d
> when
> > > >    running native but it doesnt work when running as Dom0.
> > > >
> > > >    so now the problem is:
> > > >
> > > >    with stable-2.6.32.x: graphics works in Dom0 without Vt-d but not
> with
> > > >    VT-d (neither native nor Dom0).
> > > >    with stable-2.6.33.x: graphics works with VT-d when running native
> but
> > > >    doesnt work when running as Dom0 (with or without VT-d).
> > > >
> > >
> > > stable-2.6.33.x is not maintained, and you shouldn't use it.
> > >
> > > I think Konrad has a backport of the 2.6.34 drm/dri drivers
> > > to stable-2.6.32.x somewhere.. that might help.
> > >
> > > http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > >
> > > -- Pasi
> > >
> > > >    I am experiencing this problem both with Lenovo T410, and Dell
> > > latitude
> > > >    E6410.
> > > >    Has anybody experienced this problem?
> > > >
> > > >    Thanks,
> > > >    Sanjay
> > > >
> > > >    On Fri, Oct 1, 2010 at 11:06 AM, sanjay kushwaha
> > > >    <[1]sanjay.kushwaha@gmail.com> wrote:
> > > >
> > > >      havent tried stable-2.6.32.x on Radeon. It works with nomodeset
> and
> > > >      nopat options with stable-2.6.33.x branch.
> > > >
> > > >      On Fri, Oct 1, 2010 at 10:57 AM, Konrad Rzeszutek Wilk
> > > >      <[2]konrad.wilk@oracle.com> wrote:
> > > >
> > > >        On Fri, Oct 01, 2010 at 10:06:48AM -0700, sanjay kushwaha
> wrote:
> > > >        > When I dont use nomodeset option, dom0 boots fine X runs
> > > properly.
> > > >        So Fedora
> > > >        > 13 (X86_64) distro with stable-2.6.32.x pvops kernel and
> > > >        xen-unstable works
> > > >        > fine for i915 without nomodeset option.
> > > >
> > > >        Good to hear it works for you.
> > > >
> > > >        What about your radeon laptop?
> > > >        >
> > > >        > Thanks,
> > > >        > Sanjay
> > > >        >
> > > >        > On Wed, Sep 29, 2010 at 3:56 PM, sanjay kushwaha
> > > >        > <[3]sanjay.kushwaha@gmail.com>wrote:
> > > >        >
> > > >        > > Hi Jeremy,
> > > >        > > I switched to stable-2.6.32.x branch (which is 2.6.32.21
> > > based)
> > > >        but I get
> > > >        > > the same problem. Attached is the Xorg.0.log file when I
> > > booted
> > > >        with
> > > >        > > nomodeset option.
> > > >        > >
> > > >        > > interestingly I did not see any kernel or driver crash
> > > messages in
> > > >        the
> > > >        > > dmesg output. I do see these messages multiple times in
> > > >        /var/log/messages
> > > >        > > *
> > > >        > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> GdmDisplay:
> > > >        display
> > > >        > > lasted 0.048984 seconds
> > > >        > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > >        GdmLocalDisplayFactory:
> > > >        > > maximum number of X display failures reached: check X
> server
> > > log
> > > >        for errors
> > > >        > > *
> > > >        > >
> > > >        > > Thanks,
> > > >        > > Sanjay
> > > >        > >
> > > >        > >
> > > >        > > On Wed, Sep 29, 2010 at 11:57 AM, Jeremy Fitzhardinge
> > > >        <[4]jeremy@goop.org>wrote:
> > > >        > >
> > > >        > >>  On 09/29/2010 11:12 AM, sanjay kushwaha wrote:
> > > >        > >> > Hi Folks,
> > > >        > >> > I am trying to boot latest xen-unstable on my laptop
> which
> > > has
> > > >        Intel
> > > >        > >> > i915 graphics. PVOPS dom0 is 2.6.33.6 based (from
> branch
> > > >        > >> > xen/stable-2.6.33.x)
> > > >        > >>
> > > >        > >> Don't use that branch; it isn't supported (in fact, I
> deleted
> > > it
> > > >        a while
> > > >        > >> ago).  Use xen/stable-2.6.32.x for now.
> > > >        > >>
> > > >        > >>    J
> > > >        > >>
> > > >        > >> > and the distro is fedora 13 64-bit. The graphics doesnt
> > > come up
> > > >        and it
> > > >        > >> > seems that i915 driver is crashing multiple times. If I
> > > boot in
> > > >        > >> > run-level 3 (without X) dom0 boots fine.
> > > >        > >> > I tried booting the dom0 kernel with nomodeset and
> nopat
> > > >        options
> > > >        > >> > without any success. I searched on internet and found
> that
> > > >        multiple
> > > >        > >> > people have reported similar problem but I could not
> find
> > > any
> > > >        solution.
> > > >        > >> >
> > > >        > >> > Has anybody found a solution or workaround to this
> problem?
> > > >        > >> >
> > > >        > >> > Thanks,
> > > >        > >> > Sanjay
> > > >        > >> >
> > > >        > >> > PS: I have another laptop with same version of xen and
> > > pvops
> > > >        dom0 but
> > > >        > >> > it has ATI radeon graphics card. This laptop boots dom0
> > > with
> > > >        graphics
> > > >        > >> > when I give nomodeset and nopat options (but fails if I
> > > dont
> > > >        give
> > > >        > >> > either of those two options).
> > > >        > >> >
> > > >        > >> >
> > > >        > >> >
> > > >        > >> > _______________________________________________
> > > >        > >> > Xen-devel mailing list
> > > >        > >> > [5]Xen-devel@lists.xensource.com
> > > >        > >> > [6]http://lists.xensource.com/xen-devel
> > > >        > >>
> > > >        > >>
> > > >        > >
> > > >
> > > >        > _______________________________________________
> > > >        > Xen-devel mailing list
> > > >        > [7]Xen-devel@lists.xensource.com
> > > >        > [8]http://lists.xensource.com/xen-devel
> > > >
> > > >      --
> > > >      ----------------------
> > > >      Dr. Sanjay Kumar
> > > >      Research Scientist
> > > >      Intel Corporation
> > > >
> > > >    --
> > > >    ----------------------
> > > >    Dr. Sanjay Kumar
> > > >    Research Scientist
> > > >    Intel Corporation
> > > >
> > > > References
> > > >
> > > >    Visible links
> > > >    1. mailto:sanjay.kushwaha@gmail.com
> > > >    2. mailto:konrad.wilk@oracle.com
> > > >    3. mailto:sanjay.kushwaha@gmail.com
> > > >    4. mailto:jeremy@goop.org
> > > >    5. mailto:Xen-devel@lists.xensource.com
> > > >    6. http://lists.xensource.com/xen-devel
> > > >    7. mailto:Xen-devel@lists.xensource.com
> > > >    8. http://lists.xensource.com/xen-devel
> > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > >
> > >
> >
> >
> > --
> > ----------------------
> > Dr. Sanjay Kumar
> > Research Scientist
> > Intel Corporation
>



-- 
----------------------
Dr. Sanjay Kumar
Research Scientist
Intel Corporation

[-- Attachment #1.2: Type: text/html, Size: 13186 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: New Hypercall Declaration
From: Nimgaonkar, Satyajeet @ 2010-10-07 17:36 UTC (permalink / raw)
  To: Dan Magenheimer, xen-devel@lists.xensource.com
In-Reply-To: <f7713e49-ccd1-4a39-afef-1a84cb582c86@default>


[-- Attachment #1.1: Type: text/plain, Size: 5751 bytes --]

Hi Dan,
           I followed your instruction from the below email, but still I am getting -1 for hypercall invocation. These are the steps I followed.

1. Add my hypercall in xen.h  ----  #define __HYPERVISOR_jeet1                56

2. Added it to entry.S - hypercall table ---- .quad do_mca                /* 48 */
                                                                     .quad do_jeet1                /* 56 */
                                  - hypercall_args_table ---- .byte 1 /* do_mca               */  /* 48 */
                                                                             .byte 0 /* do_jeet1             */  /* 56 */

3. Then declared my hypercall in asm-x86/hypercall.h ---- void do_jeet1(void);

4. Then calling it in domctl.c in xen/common --- void do_jeet1(void){

   printk ("Successfull Hypercall made to __HYPERVISOR_jeet1");

}

5. Declared a function in xc_domain.c in xen/tools to call this hypercall

   int hypercall_test(int handle){

    int rc;
    int arg=0;
    //int cmd=1;
    //
    //int test;
    /* Hypercall definitions */

    DECLARE_HYPERCALL;
    hypercall.op     = __HYPERVISOR_jeet1;
    rc = do_xen_hypercall(handle, &hypercall);
    hypercall.arg[0] = 0;
    hypercall.arg[1] = (unsigned long)&arg;
    //printf ("Hypercall Details: %d\n", rc);
    //xc_interface_close(handle);
    return rc;
}

6. Then wrote a userlevel program to call function hypercall_test and invoke my hypercall.

    #include <xenctrl.h>
#include <stdio.h>



int main(){

     printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
     int handle, rc;

         /* Acquire Hypervisor Interface Handle.
            This handle goes as the first argument for the function do_xen_hypercall()
         */

     handle = xc_interface_open();
     printf ("Acquired handle to Xen Hypervisor:%d\n",handle);


     rc = hypercall_test(handle);
     printf ("Hypercall Details: %d\n", rc);

     xc_interface_close(handle);
     printf ("Hypervisor handle closed\n");

     return 0;

}


I compiled entire xen, installed it and booted into the atest compiled xen. But still my userlevel program compiles error free but returns me a -1 error for hypercall invocation. Can you please tell me what is that I doing wrong.
Thanks.

Regards,
Satyajeet Nimgaonkar
________________________________
From: Dan Magenheimer [dan.magenheimer@oracle.com]
Sent: Thursday, September 30, 2010 4:47 PM
To: Nimgaonkar, Satyajeet; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration

Do you understand that you must also change the hypervisor to recognize and do something with your new hypercall?  Your userland code may actually be working and the hypercall may actually be resulting in an entry into the hypervisor, but unless the hypervisor is modified to recognize the new hypercall (#56) and do something with it, the hypervisor will generate a return value of -1 (essentially saying “I don’t recognize this hypercall number”).

If you have modified the hypervisor, please share that patch.  If not, you will need to modify at least  the hypercall_table and the hypercall_args_table in entry.S (under x86, x86_64, and x86_64/compat, or all three, depending on the bit-ness of your hypervisor and guest) and create a do_my_hypercall() routine somewhere.  Then of course you will need to ensure that you are properly building, installing, and booting your newly modified hypervisor.

Printk’s done inside the hypervisor can be viewed using “xm dmesg” or via a properly configured serial port.

Use “xm info” and look at cc_compile_date to ensure you are booting your newly modified hypervisor.

Hope that helps,
Dan

From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@my.unt.edu]
Sent: Thursday, September 30, 2010 4:03 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] New Hypercall Declaration

Hello Xen Developers,

 I am currently working on declaring a new hypercall in Xen.
For this i have declared my hypercall in xen.h -
#define __HYPERVISOR_jeet1                56

Then I modified the xcom_privcmd.c to accomodate my hypercall -
         case __HYPERVISOR_jeet1:
                 printk("Successfull Hypercall made to
__HYPERVISOR_jeet1");

I defined the structure for the Hypercall in xc_domain.c

int hypercall_test(int handle){

    int rc;

    /* Hypercall definitions */

    DECLARE_HYPERCALL;
    hypercall.op     = __HYPERVISOR_jeet1;
    rc = do_xen_hypercall(handle, &hypercall);
    hypercall.arg[0] = 0;
    hypercall.arg[1] = 1;
    //printf ("Hypercall Details: %d\n", rc);
    //xc_interface_close(handle);
    return rc;
}

And then I am calling this Hypercall through an user level program-

#include <xenctrl.h>
#include <stdio.h>



int main(){

     printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
     int handle, rc;

         /* Acquire Hypervisor Interface Handle.
            This handle goes as the first argument for the function do_xen_hypercall()
         */

     handle = xc_interface_open();
     printf ("Acquired handle to Xen Hypervisor:%d\n",handle);


     rc = hypercall_test(handle);
     printf ("Hypercall Details: %d\n", rc);

     xc_interface_close(handle);

     return 0;

}


The program compiles properly but gives me -1 error for rc. I have posted the same query and I got replies on it. But even after trying many things, I am still stuck with this problem. Can anyone please tell me what I am doing wrong here. Also please tell me where
should I view the output of printk in xen.

Thanks in advance.

Regards,
Satyajeet Nimgaonkar

[-- Attachment #1.2: Type: text/html, Size: 13767 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: [PATCH v3] OMAP: NAND: Fix static declaration warning
From: Vimal Singh @ 2010-10-07 17:35 UTC (permalink / raw)
  To: G, Manjunath Kondaiah
  Cc: linux-omap, linux-arm-kernel, linux-mtd, Tony Lindgren,
	Nishanth Menon
In-Reply-To: <1286315819-5906-1-git-send-email-manjugk@ti.com>

On Wed, Oct 6, 2010 at 3:26 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> This patch fixes sparse warning for static declaration of variable "use_dma"
>
> drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static?
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mtd@lists.infradead.org
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Nishanth Menon <nm@ti.com>
> ---
> Changes since v1:
>  - no logical changes, patch seperated from series based Tony's suggestion.
>
>  drivers/mtd/nand/omap2.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 133d515..439e80d 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -111,11 +111,11 @@ static int use_dma = 1;
>  module_param(use_dma, bool, 0);
>  MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
>  #else
> -const int use_dma;
> +static const int use_dma;
>  #endif
>  #else
>  const int use_prefetch;
> -const int use_dma;
> +static const int use_dma;

I did not understand, why did it not pointed same error for 'const int
use_prefetch'?

-- 
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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

* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Alan Stern @ 2010-10-07 17:35 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Rafael J. Wysocki, Linux-pm mailing list, Partha Basak,
	linux-omap
In-Reply-To: <87aamqaqt9.fsf@deeprootsystems.com>

On Thu, 7 Oct 2010, Kevin Hilman wrote:

> My confusion is not about the use of spinlocks, it's a question of what
> is being busy-waited for, and the thread that is being waited for is
> going to complete when interrupts are disabled.
> 
> Sorry to be dense, but can you (re)summarize what you're proposing as I
> think I'm getting mixed up with all the various options we've been
> tossing around.
> 
> If it can work, I'm certainly in favor of a busy-wait approach as it 
> really ensures that sync requests are handled quickly.

Okay, here's the story in a nutshell.  Allowing a subsystem's or
driver's runtime-PM callbacks to run with interrupts disabled faces two
obstacles:

   (1): We don't want two different CPUs to run callbacks for the
	same device at the same time.  So if a callback is already
	running on one CPU (i.e., if the device's runtime status is
	either SUSPENDING or RESUMING) then another CPU can't be
	allowed to invoke a callback.

	Thus, you can't do a synchronous pm_runtime_resume_irq()
	if the device is in the middle of a suspend or resume
	operation.  We're left with two choices: Fail the synchronous
	call and force the driver to defer matters to a workqueue
	(possibly masking an IRQ line in the meantime), or busy-wait
	until the concurrent operation finishes.

	If the PM core simply avoids releasing dev->power.lock before
	invoking the runtime_suspend or runtime_resume callback, the
	end result is almost the same as with busy-waiting.

   (2): In general we can't resume a device if its parent is suspended.
	If the parent's runtime_resume routine needs to run with
	interrupts enabled then there's no way to resume the device
	while keeping interrupts disabled.

	Possible solutions involve, again, deferring matters to a
	workqueue, or else simply not allowing the situation to arise
	in the first place (forbid a device to have interrupt-disabled 
	callbacks unless its parent does too or the parent doesn't use 
	runtime PM at all).

In general I'm against the solutions that require a workqueue.  Raphael 
appears to favor workqueues for (1) and be against them for (2).

Alan Stern


^ permalink raw reply

* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Alan Stern @ 2010-10-07 17:35 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <87aamqaqt9.fsf@deeprootsystems.com>

On Thu, 7 Oct 2010, Kevin Hilman wrote:

> My confusion is not about the use of spinlocks, it's a question of what
> is being busy-waited for, and the thread that is being waited for is
> going to complete when interrupts are disabled.
> 
> Sorry to be dense, but can you (re)summarize what you're proposing as I
> think I'm getting mixed up with all the various options we've been
> tossing around.
> 
> If it can work, I'm certainly in favor of a busy-wait approach as it 
> really ensures that sync requests are handled quickly.

Okay, here's the story in a nutshell.  Allowing a subsystem's or
driver's runtime-PM callbacks to run with interrupts disabled faces two
obstacles:

   (1): We don't want two different CPUs to run callbacks for the
	same device at the same time.  So if a callback is already
	running on one CPU (i.e., if the device's runtime status is
	either SUSPENDING or RESUMING) then another CPU can't be
	allowed to invoke a callback.

	Thus, you can't do a synchronous pm_runtime_resume_irq()
	if the device is in the middle of a suspend or resume
	operation.  We're left with two choices: Fail the synchronous
	call and force the driver to defer matters to a workqueue
	(possibly masking an IRQ line in the meantime), or busy-wait
	until the concurrent operation finishes.

	If the PM core simply avoids releasing dev->power.lock before
	invoking the runtime_suspend or runtime_resume callback, the
	end result is almost the same as with busy-waiting.

   (2): In general we can't resume a device if its parent is suspended.
	If the parent's runtime_resume routine needs to run with
	interrupts enabled then there's no way to resume the device
	while keeping interrupts disabled.

	Possible solutions involve, again, deferring matters to a
	workqueue, or else simply not allowing the situation to arise
	in the first place (forbid a device to have interrupt-disabled 
	callbacks unless its parent does too or the parent doesn't use 
	runtime PM at all).

In general I'm against the solutions that require a workqueue.  Raphael 
appears to favor workqueues for (1) and be against them for (2).

Alan Stern

^ permalink raw reply

* [PATCH v3] OMAP: NAND: Fix static declaration warning
From: Vimal Singh @ 2010-10-07 17:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1286315819-5906-1-git-send-email-manjugk@ti.com>

On Wed, Oct 6, 2010 at 3:26 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> This patch fixes sparse warning for static declaration of variable "use_dma"
>
> drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static?
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mtd at lists.infradead.org
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Nishanth Menon <nm@ti.com>
> ---
> Changes since v1:
> ?- no logical changes, patch seperated from series based Tony's suggestion.
>
> ?drivers/mtd/nand/omap2.c | ? ?4 ++--
> ?1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 133d515..439e80d 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -111,11 +111,11 @@ static int use_dma = 1;
> ?module_param(use_dma, bool, 0);
> ?MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
> ?#else
> -const int use_dma;
> +static const int use_dma;
> ?#endif
> ?#else
> ?const int use_prefetch;
> -const int use_dma;
> +static const int use_dma;

I did not understand, why did it not pointed same error for 'const int
use_prefetch'?

-- 
Regards,
Vimal Singh

^ permalink raw reply

* Re: [PATCH v3] OMAP: NAND: Fix static declaration warning
From: Vimal Singh @ 2010-10-07 17:35 UTC (permalink / raw)
  To: G, Manjunath Kondaiah
  Cc: Tony Lindgren, Nishanth Menon, linux-omap, linux-mtd,
	linux-arm-kernel
In-Reply-To: <1286315819-5906-1-git-send-email-manjugk@ti.com>

On Wed, Oct 6, 2010 at 3:26 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> This patch fixes sparse warning for static declaration of variable "use_dma"
>
> drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static?
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-mtd@lists.infradead.org
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Nishanth Menon <nm@ti.com>
> ---
> Changes since v1:
>  - no logical changes, patch seperated from series based Tony's suggestion.
>
>  drivers/mtd/nand/omap2.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 133d515..439e80d 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -111,11 +111,11 @@ static int use_dma = 1;
>  module_param(use_dma, bool, 0);
>  MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
>  #else
> -const int use_dma;
> +static const int use_dma;
>  #endif
>  #else
>  const int use_prefetch;
> -const int use_dma;
> +static const int use_dma;

I did not understand, why did it not pointed same error for 'const int
use_prefetch'?

-- 
Regards,
Vimal Singh

^ permalink raw reply

* Re: Linux 2.6.36-rc7
From: Eric Paris @ 2010-10-07 17:33 UTC (permalink / raw)
  To: Tvrtko Ursulin; +Cc: Linus Torvalds, Linux Kernel Mailing List, agruen
In-Reply-To: <201010071815.54303.tvrtko.ursulin@sophos.com>

On Thu, 2010-10-07 at 18:15 +0100, Tvrtko Ursulin wrote:
> On Thursday 07 Oct 2010 17:10:46 Tvrtko Ursulin wrote:
> > On Wednesday 06 Oct 2010 22:45:13 Linus Torvalds wrote:

> Priority argument was dropped from the fanotify_init syscall, and since it is
> a syscall once released it is set in stone. Without the priority argument, how
> are multiple clients supposed to be ordered?
> 
> Co-existence between multiple clients was something which was supposed to be
> designed in from the start. Use cases like hierarchical storage management,
> anti-malware and content indexing should all be able to co-exist. Without a
> priority argument I do not see how it can be assured HSM sees the perm event
> before anti-malware, and content indexing after both of them? If there was any
> discussion about dropping priority I missed it. :(

Shit.  I'm trying to remember the logic.  hrmph....   You could have a
real interface issue....  Shit.  Let me think about it for an hour or
two.

Original idea of priorities was to allow multiple permissions decision
makers to co-exist without having the livelock problem of each trying to
grant and deny access to each other.  That was solved with the
O_NONOTIFY hack and I think the priority was then thought to be useless.
But you're absolutely right, it isn't useless if we consider that an HSM
might need to run first to make sure data exists on disk before an
indexer looks at the data.

I see two possibilities off the top of my head:

I could just slap an (unused) priority field onto the end of the
fanotify_init() syscall (assuming Linus doesn't murder me) so we can
build that support out with explicit priorities down the line, which I
think might be overkill, or

The other option (without breaking ABI as it stands today) is to define
some set of the fanotify_init() flags to be a priority field, we've got
32 bits and only use 2 of them so giving 4-8 bits of that as a priority
(next cycle) isn't an issue and can be easily backwards compatible.

-Eric


^ permalink raw reply

* Re: [Xenomai-core] Overcoming the "foreign" stack
From: Jan Kiszka @ 2010-10-07 17:34 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: Xenomai core
In-Reply-To: <1286471281.13186.79.camel@domain.hid>

Am 07.10.2010 19:08, Philippe Gerum wrote:
> On Wed, 2010-10-06 at 11:20 +0200, Jan Kiszka wrote: 
>> Am 05.10.2010 16:21, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Am 05.10.2010 15:50, Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote:
>>>>>>>>> Jan Kiszka wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> quite a few limitations and complications of using Linux services over
>>>>>>>>>> non-Linux domains relate to potentially invalid "current" and
>>>>>>>>>> "thread_info". The non-Linux domain could maintain their own kernel
>>>>>>>>>> stacks while Linux tend to derive current and thread_info from the stack
>>>>>>>>>> pointer. This is not an issue anymore on x86-64 (both states are stored
>>>>>>>>>> in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the
>>>>>>>>>> stack and may continue to do so.
>>>>>>>>>>
>>>>>>>>>> I just looked into this thing again as I'm evaluating ways to exploit
>>>>>>>>>> the kernel's tracing framework also under Xenomai. Unfortunately, it
>>>>>>>>>> does a lot of fiddling with preempt_count and need_resched, so patching
>>>>>>>>>> it for Xenomai use would become a maintenance nightmare.
>>>>>>>>>>
>>>>>>>>>> An alternative, also for other use cases like kgdb and probably perf, is
>>>>>>>>>> to get rid of our dependency on home-grown stacks. I think we are on
>>>>>>>>>> that way already as in-kernel skins have been deprecated. The only
>>>>>>>>>> remaining user after them will be RTDM driver tasks. But I think those
>>>>>>>>>> could simply become in-kernel shadows of kthreads which would bind their
>>>>>>>>>> stacks to what Linux provides. Moreover, Xenomai could start updating
>>>>>>>>>> "current" and "thread_info" on context switches (unless this already
>>>>>>>>>> happens implicitly). That would give us proper contexts for system-level
>>>>>>>>>> tracing and profiling.
>>>>>>>>>>
>>>>>>>>>> My key question is currently if and how much of this could be realized
>>>>>>>>>> in 2.6. Could we drop in-kernel skins in that version? If not, what
>>>>>>>>>> about disabling them by default, converting RTDM tasks to a
>>>>>>>>>> kthread-based approach, and enabling tracing etc. only in that case?
>>>>>>>>>> However, this might be a bit fragile unless we can establish
>>>>>>>>>> compile-time or run-time requirements negotiation between Adeos and its
>>>>>>>>>> users (Xenomai) about the stack model.
>>>>>>>>> A stupid question: why not make things the other way around: patch the
>>>>>>>>> current and current_thread_info functions to be made I-pipe aware and
>>>>>>>>> use an "ipipe_current" pointer to the current thread task_struct. Of
>>>>>>>>> course, there are places where the current or current_thread_info macros
>>>>>>>>> are implemented in assembly, so it may be not simple as it sounds, but
>>>>>>>>> it would allow to keep 128 Kb stacks if we want. This also means that we
>>>>>>>>> would have to put a task_struct at the bottom of every Xenomai task.
>>>>>>>> First of all, overhead vs. maintenance. Either every access to
>>>>>>>> preempt_count() would require a check for the current domain and its
>>>>>>>> foreign stack flag, or I would have to patch dozens (if that is enough)
>>>>>>>> of code sites in the tracer framework.
>>>>>>> No. I mean we would dereference a pointer named ipipe_current. That is
>>>>>>> all, no other check. This pointer would be maintained elsewhere. And we
>>>>>>> modify the "current" macro, like:
>>>>>>>
>>>>>>> #ifdef CONFIG_IPIPE
>>>>>>> extern struct task_struct *ipipe_current;
>>>>>>> #define current ipipe_current
>>>>>>> #endif
>>>>>>>
>>>>>>> Any calll site gets modified automatically. Or current_thread_info, if
>>>>>>> it is current_thread_info which is obtained using the stack pointer mask
>>>>>>> trick.
>>>>>> The stack pointer mask trick only works with fixed-sized stacks, not a
>>>>>> guaranteed property of in-kernel Xenomai threads.
>>>>> Precisely the reason why I propose to replace it with a global variable
>>>>> reference, or a per-cpu variable for SMP systems.
>>>>
>>>> Then why is Linux not using this in favor of the stack pointer approach
>>>> on, say, ARM?
>>>>
>>>> For sure, we can patch all Adeos-supported archs away from stack-based
>>>> to per-cpu current & thread_info, but I don't feel comfortable with this
>>>> in some way invasive approach as well. Well, maybe it's just my personal
>>>> misperception.
>>>
>>> It is as much invasive as modifying local_irq_save/local_irq_restore.
>>> The real question about the global pointer approach, is, if it so much
>>> less efficient, how does Xenomai, which uses this scheme, manage to have
>>> good performances on ARM?
>>
>> Xenomai has no heavily-used preempt_disable/enable that is built on top
>> of thread_info. But I also have no numbers on this.
>>
>> I looked closer at the kernel dependencies on a fixed stack size.
>> Besides current and thread_info, further features that make use of this
>> are stack unwinding (boundary checks) and overflow checking. So while we
>> can work around the dependency for some tracing requirements, I really
>> see no point in heading for this long-term. It just creates more subtle
>> patching needs in Adeos, and it also requires work on Xenomai side. I
>> really think it's better provide a compatible context to reduce
>> maintenance efforts.
>>
>> So I played a bit with converting RTDM tasks to in-kernel shadows. It
>> works but needs more fine-tuning. My proposal for 2.6 now looks like this:
>>
>>  - add mm-less shadow support to the nucleus (changes in
>>    xnarch_switch_to and xnshadow_map)
>>  - convert RTDM tasks to in-kernel shadows
>>  - switch current and thread_info on Xenomai task switches
>>  - make in-kernel skins optional, default off
>>  - let in-kernel skins dependent on disabled tracing
> 
> I agree with your approach of moving to kernel space shadows, this is
> the best way to get rid of foreign stacks. Those are a relic of the
> kernel-only era, this introduces painful constraints, e.g. in low-level
> thread switching code (i.e. so-called "hybrid" scheduling) and other
> weirdnesses. This definitely has to go.
> 
> I'm on a wait and see stance about generalizing the use of the ftrace
> framework for our needs; like Gilles saw with ARM, I must admit that I
> did notice a massive overhead on low-end ppc as well when we moved the
> pipeline tracer over it. I'm aware of the mcount optimizations that
> should be there when cycles really matter, and that ftrace does branch
> directly to the trace function when only a single one exists, but this
> may not be easy to keep after the generalization has taken place.
> Anyway, I'll wait for more data to make my opinion.

As I said, ftrace is more the a simple mcount-tracer. And it's standard,
distros start to enable it in their production kernels these days
(except for the function tracer).

If the overhead of the ftrace's mcount is too high on low-end platforms
(I personally haven't tried it there yet), it would probably be a good
idea to develop some optimizations or allow some variant that does not
suffer that much - but upstream then.

> 
> However, those changes can't be targeted at 2.6. The rationale for
> issuing 2.6 is really about cleaning up some ABI issues and merging
> invasive but non-critical infrastructure changes, so that we can
> maintain the 2.x series for a long time without being stuck by the ABI
> constraints of 2.5.x. Your proposal is clean material for 3.x though,
> given that we won't even have to bother with in-kernel skin APIs there.

OK, I see. This will be too late for our next version I'm afraid.

But maybe we can establish some intermediate solutions, at least for
x86-64 where we do not have that many problems with kernel-stack-based
information. That would allow to explore the potentials of ftrace and
tools a bit earlier.

> 
> This said, I understand we need a branch to experiment radical changes
> aimed at 3.x, but xenomai-head is no place for that. I have been
> tracking -head for some time, doing massive cuts in the code to
> eliminate most of the obvious legacy we don't want to care about anymore
> (e.g. 2.4 kernel support, in-kernel skin APIs, and a few others). I will
> shortly open a new tree on git.xenomai.org called "forge" with that code
> base, so that we have the proper playground to get wild with our
> chainsaws in the Xenomai core aimed at 3.x.

Looking forward to seeing this.

I actually ran into one compatibility conflict with my shadow rtdm task
as well: Someone specified rtdm_task_init as RT-safe, and some strange
network stack called RTnet indeed made use of this. Would be easier to
simply require a driver update for a new RTDM version than establishing
a compatibility workaround.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux


^ permalink raw reply

* updating the source tree
From: Grzesiek Sójka @ 2010-10-07 17:34 UTC (permalink / raw)
  To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Hi there,

I downloaded the nouveau/linux-2.6 using the following:
git clone --depth 1 git://anongit.freedesktop.org/nouveau/linux-2.6
Is there an easy way to update it to the current version (reversing all 
the changes I made) without downloading all the files again??

Thanks for your help in advance.

greg

^ permalink raw reply

* Re: [PATCH 2/2] device-assignment: Allow PCI to manage the option ROM
From: Alex Williamson @ 2010-10-07 17:34 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: kvm, ddutile, chrisw
In-Reply-To: <20101007171858.GA15537@redhat.com>

On Thu, 2010-10-07 at 19:18 +0200, Michael S. Tsirkin wrote:
> On Mon, Oct 04, 2010 at 03:26:30PM -0600, Alex Williamson wrote:
> > --- a/hw/device-assignment.c
> > +++ b/hw/device-assignment.c
...
> > @@ -1644,58 +1621,64 @@ void add_assigned_devices(PCIBus *bus, const char **devices, int n_devices)
> >   */
> >  static void assigned_dev_load_option_rom(AssignedDevice *dev)
> >  {
> > -    int size, len, ret;
> > -    void *buf;
> > +    char name[32], rom_file[64];
> >      FILE *fp;
> > -    uint8_t i = 1;
> > -    char rom_file[64];
> > +    uint8_t val;
> > +    struct stat st;
> > +    void *ptr;
> > +
> > +    /* If loading ROM from file, pci handles it */
> > +    if (dev->dev.romfile || !dev->dev.rom_bar)
> > +        return;
> >  
> >      snprintf(rom_file, sizeof(rom_file),
> >               "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
> >               dev->host.seg, dev->host.bus, dev->host.dev, dev->host.func);
> >  
> > -    if (access(rom_file, F_OK))
> > +    if (stat(rom_file, &st)) {
> >          return;
> > +    }
> >  
> 
> Just a note that stat on the ROM sysfs file returns window size,
> not the ROM size. So this allocates more ram than really necessary for
> ROM. Real size is returned by fread.
> 
> Do we care?

That was my intention with using stat.  I thought that by default the
ROM BAR should match physical hardware, so even if the contents could be
rounded down to a smaller size, we maintain the size of the physical
device.  To use the minimum size, the contents could be extracted using
pci-sysfs and passed with the romfile option, or the ROM could be
disabled altogether with the rombar=0 option.  Sound reasonable?
Thanks,

Alex


^ permalink raw reply

* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-07 17:33 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4CAB6B08.4050801@candelatech.com>


In case it helps, here is a dump of where the corrupted SKB was deleted.

I added debugging to slub to get this information, but it looks like
it's correct to me.


Reading symbols from /home/greearb/kernel/2.6/wireless-testing-dbg.p4s/net/mac80211/mac80211.ko...done.
(gdb) l *(ieee80211_rx+0x74d)
0x13751 is in ieee80211_rx (/home/greearb/git/linux.wireless-testing/include/linux/rcupdate.h:346).
341	 *
342	 * See rcu_read_lock() for more information.
343	 */
344	static inline void rcu_read_unlock(void)
345	{
346		rcu_read_release();
347		__release(RCU);
348		__rcu_read_unlock();
349	}
350	
(gdb)


# I don't really know what that second address means, but just in case it's useful,
# I printed it out here:

(gdb) l *(ieee80211_rx+0x7b4)
0x137b8 is in ieee80211_process_measurement_req (/home/greearb/git/linux.wireless-testing/net/mac80211/spectmgmt.c:74).
69	}
70	
71	void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
72					       struct ieee80211_mgmt *mgmt,
73					       size_t len)
74	{
75		/*
76		 * Ignoring measurement request is spec violation.
77		 * Mandatory measurements must be reported optional
78		 * measurements might be refused or reported incapable


INFO: Freed in skb_release_data+0x8c/0x90 age=122 cpu=1 pid=0
         set_track+0x3c/0x89
         __slab_free+0x17f/0x1ba
         skb_release_data+0x8c/0x90
         kfree+0xaf/0xdf
         skb_release_data+0x8c/0x90
         skb_release_data+0x8c/0x90
         skb_release_data+0x8c/0x90
         __kfree_skb+0x12/0x6d
         consume_skb+0x2a/0x2c
         ieee80211_rx+0x74d/0x7b4 [mac80211]
         __kmalloc_track_caller+0xcd/0xf2
         trace_hardirqs_on_caller+0xeb/0x125
         ath_rx_send_to_mac80211+0x5a/0x60 [ath9k]
         trace_hardirqs_on+0xb/0xd

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* [Qemu-devel] Re: [PATCH 09/11] i386: avoid a write only variable
From: Blue Swirl @ 2010-10-07 17:32 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4CAD7657.8080400@redhat.com>

On Thu, Oct 7, 2010 at 7:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/06/2010 11:34 PM, Blue Swirl wrote:
>>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/target-i386/op_helper.c: In function 'switch_tss':
>> /src/qemu/target-i386/op_helper.c:283:53: error: variable 'new_trap'
>> set but not used [-Werror=unused-but-set-variable]
>>
>> Fix by deleting the variable.
>
> Again, this warning tells us the emulation is incorrect, so it's wrong to
> remove it.

The warning tells us that the emulation is unfinished.

It's probably unfinished because debugging TSS switches hasn't ever
been needed by anyone. If anyone in the future cares enough about T
bit, it's easy to implement it even after this part has been removed.

But if someone proposes a better patch, I'd be happy to use that
instead of this.

^ permalink raw reply


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.