* Re: pvops Dom0 graphics doesnt work with Intel i915
From: sanjay kushwaha @ 2010-10-07 22:44 UTC (permalink / raw)
To: Kay, Allen M; +Cc: Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk
In-Reply-To: <987664A83D2D224EAE907B061CE93D530163EA9530@orsmsx505.amr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 11775 bytes --]
Hi Allen,
Indeed I needed this workaround. Now graphics works fine with VT-d with this
xen tree.
Thanks,
Sanjay
On Thu, Oct 7, 2010 at 3:05 PM, Kay, Allen M <allen.m.kay@intel.com> wrote:
> Sanjay,
>
>
>
> Have you tried the latest xen-unstable staging tree? It has a workaround
> for T410 VT-d graphics issue caused by Lenovo BIOS. This might be the
> workaround you need:
>
>
>
> http://xenbits.xensource.com/staging/xen-unstable.hg?rev/4beee5779122
>
>
>
> Allen
>
>
>
> *From:* xen-devel-bounces@lists.xensource.com [mailto:
> xen-devel-bounces@lists.xensource.com] *On Behalf Of *sanjay kushwaha
> *Sent:* Thursday, October 07, 2010 12:13 PM
> *To:* Konrad Rzeszutek Wilk
> *Cc:* Jeremy Fitzhardinge; xen-devel
> *Subject:* Re: [Xen-devel] pvops Dom0 graphics doesnt work with Intel i915
>
>
>
> Hi Konrad,
> Unfortunately T410 doesnt have a serial port and neither does the docking
> station. I havent had any success with USB-to-Serial port dongles in the
> past. is there any way to get the serial port output?
>
> Thanks,
> Sanjay
>
> On Thu, Oct 7, 2010 at 11:05 AM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
>
> On Thu, Oct 07, 2010 at 10:36:34AM -0700, sanjay kushwaha wrote:
> > 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).
>
> Are there any warnings/debug messages in the serial log? Please follow
> the PVOPS Wiki on how to enable all the debug options.
>
> >
> >
> > 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
>
> > _______________________________________________
> > 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: 19961 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
* + sgi-altix-ia64-mmtimer-eliminate-long-interval-timer-holdoffs.patch added to -mm tree
From: akpm @ 2010-10-07 22:43 UTC (permalink / raw)
To: mm-commits; +Cc: sivanich, tony.luck
The patch titled
SGI Altix IA64 mmtimer: eliminate long interval timer holdoffs
has been added to the -mm tree. Its filename is
sgi-altix-ia64-mmtimer-eliminate-long-interval-timer-holdoffs.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: SGI Altix IA64 mmtimer: eliminate long interval timer holdoffs
From: Dimitri Sivanich <sivanich@sgi.com>
This patch for SGI Altix/IA64 eliminates interval long timer holdoffs in
cases where we don't start an interval timer before the expiration time.
This sometimes happens when a number of interval timers on the same shub
with the same interval run simultaneously.
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/char/mmtimer.c | 55 +++++++++++++++++++--------------------
1 file changed, 27 insertions(+), 28 deletions(-)
diff -puN drivers/char/mmtimer.c~sgi-altix-ia64-mmtimer-eliminate-long-interval-timer-holdoffs drivers/char/mmtimer.c
--- a/drivers/char/mmtimer.c~sgi-altix-ia64-mmtimer-eliminate-long-interval-timer-holdoffs
+++ a/drivers/char/mmtimer.c
@@ -176,9 +176,8 @@ static void mmtimer_setup_int_2(int cpu,
* in order to insure that the setup succeeds in a deterministic time frame.
* It will check if the interrupt setup succeeded.
*/
-static int mmtimer_setup(int cpu, int comparator, unsigned long expires)
+static int mmtimer_setup(int cpu, int comparator, unsigned long expires, u64 *r)
{
-
switch (comparator) {
case 0:
mmtimer_setup_int_0(cpu, expires);
@@ -191,7 +190,8 @@ static int mmtimer_setup(int cpu, int co
break;
}
/* We might've missed our expiration time */
- if (rtc_time() <= expires)
+ *r = rtc_time();
+ if (*r <= expires)
return 1;
/*
@@ -227,6 +227,8 @@ static int mmtimer_disable_int(long nasi
#define TIMER_OFF 0xbadcabLL /* Timer is not setup */
#define TIMER_SET 0 /* Comparator is set for this timer */
+#define MMTIMER_INTRVL_RETRY_INCR_DEFAULT 40
+
/* There is one of these for each timer */
struct mmtimer {
struct rb_node list;
@@ -242,6 +244,10 @@ struct mmtimer_node {
};
static struct mmtimer_node *timers;
+static unsigned mmtimer_intrvl_retry_incr = MMTIMER_INTRVL_RETRY_INCR_DEFAULT;
+module_param(mmtimer_intrvl_retry_incr, uint, 0644);
+MODULE_PARM_DESC(mmtimer_intrvl_retry_incr,
+ "RTC ticks to add to expiration on interval retry (default 40)");
/*
* Add a new mmtimer struct to the node's mmtimer list.
@@ -289,7 +295,8 @@ static void mmtimer_set_next_timer(int n
struct mmtimer_node *n = &timers[nodeid];
struct mmtimer *x;
struct k_itimer *t;
- int o;
+ u64 expires, exp, r;
+ int i;
restart:
if (n->next == NULL)
@@ -300,7 +307,7 @@ restart:
if (!t->it.mmtimer.incr) {
/* Not an interval timer */
if (!mmtimer_setup(x->cpu, COMPARATOR,
- t->it.mmtimer.expires)) {
+ t->it.mmtimer.expires, &r)) {
/* Late setup, fire now */
tasklet_schedule(&n->tasklet);
}
@@ -308,14 +315,21 @@ restart:
}
/* Interval timer */
- o = 0;
- while (!mmtimer_setup(x->cpu, COMPARATOR, t->it.mmtimer.expires)) {
- unsigned long e, e1;
- struct rb_node *next;
- t->it.mmtimer.expires += t->it.mmtimer.incr << o;
- t->it_overrun += 1 << o;
- o++;
- if (o > 20) {
+ i = 0;
+ expires = exp = t->it.mmtimer.expires;
+ while (!mmtimer_setup(x->cpu, COMPARATOR, expires, &r)) {
+ int to;
+
+ i++;
+ expires = r + mmtimer_intrvl_retry_incr + (1 << i);
+ /* Calculate overruns as we go. */
+ to = ((u64)(expires - exp) / t->it.mmtimer.incr);
+ if (to) {
+ t->it_overrun += to;
+ t->it.mmtimer.expires += t->it.mmtimer.incr * to;
+ exp = t->it.mmtimer.expires;
+ }
+ if (i > 20) {
printk(KERN_ALERT "mmtimer: cannot reschedule timer\n");
t->it.mmtimer.clock = TIMER_OFF;
n->next = rb_next(&x->list);
@@ -323,21 +337,6 @@ restart:
kfree(x);
goto restart;
}
-
- e = t->it.mmtimer.expires;
- next = rb_next(&x->list);
-
- if (next == NULL)
- continue;
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Sage Weil @ 2010-10-07 22:45 UTC (permalink / raw)
To: Anthony Liguori
Cc: Yehuda Sadeh Weinraub, Kevin Wolf, kvm, qemu-devel, ceph-devel,
Christian Brunner
In-Reply-To: <4CAE41BD.2070508@codemonkey.ws>
On Thu, 7 Oct 2010, Anthony Liguori wrote:
> On 10/07/2010 04:49 PM, Yehuda Sadeh Weinraub wrote:
> > On Thu, Oct 7, 2010 at 2:04 PM, Anthony Liguori<anthony@codemonkey.ws>
> > wrote:
> >
> > > On 10/07/2010 03:47 PM, Yehuda Sadeh Weinraub wrote:
> > >
> > > > > How is that possible? Are the callbacks delivered in the context of a
> > > > > different thread? If so, don't you need locking?
> > > > >
> > > > >
> > > > Not sure I'm completely following you. The callbacks are delivered in
> > > > the context of a different thread, but won't run concurrently.
> > > >
> > > Concurrently to what? How do you prevent them from running concurrently
> > > with qemu?
> > >
> > There are two types of callbacks. The first is for rados aio
> > completions, and the second one is the one added later for the fd glue
> > layer.
> >
>
> This is a bad architecture for something like qemu. You could create a
> pipe and use the pipe to signal to qemu. Same principle as eventfd.
> Ideally, you would do this in the library itself.
I'm sorry, I'm having a hard time understanding what it is you're
objecting to, or what you would prefer, as there are two different things
we're talking about here (callbacks and fd glue/pipes). (Please bear with
me as I am not a qemu expert!)
The first is the aio completion. You said a few messages back:
> It looks like you just use the eventfd to signal aio completion
> callbacks. A better way to do this would be to schedule a bottom half.
This is what we're doing. The librados makes a callback to rbd.c's
rbd_finish_aiocb(), which updates some internal rbd accounting and then
calls qemu_bh_schedule(). Is that part right?
The second part is an fd (currently created via eventfd(), but I don't
think it matters where it comes from) that was later added because
qemu_aio_flush() wouldn't trigger when our aio's completed (and scheduled
the bottom halves). This was proposed by Simone Gotti, who had problems
with live migration:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg35516.html
Apparently calling the bottom half isn't sufficient to wake up a blocked
qemu_aio_flush()? His solution was to create an eventfd() fd, write a
word to it in the aio completion callback (before we schedule the bh), and
add the necessary callbacks to make qemu_aio_flush() behave.
Is the problem simply that we should be using pipe(2) instead of
eventfd(2)?
So far I've heard that we should be scheduling the bottom halves (we are),
and we should be using a pipe to signal qemu (we're using an fd created by
eventfd(2)).
Thanks,
sage
>
> Regards,
>
> Anthony Liguori
>
> > The first callback, called by librados whenever aio completes, runs in
> > the context of a single librados thread:
> >
> > +static void rbd_finish_aiocb(rados_completion_t c, RADOSCB *rcb)
> > +{
> > + RBDAIOCB *acb = rcb->acb;
> > rcb is per a single aio. Was created before and will be destroyed
> > here, whereas acb is shared between a few aios, however, it was
> > generated before the first aio was created.
> >
> > + int64_t r;
> > + uint64_t buf = 1;
> > + int i;
> > +
> > + acb->aiocnt--;
> >
> > acb->aiocnt has been set before initiating all the aios, so it's ok to
> > touch it now. Same goes to all acb fields.
> >
> > + r = rados_aio_get_return_value(c);
> > + rados_aio_release(c);
> > + if (acb->write) {
> > + if (r< 0) {
> > + acb->ret = r;
> > + acb->error = 1;
> > + } else if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else {
> > + if (r == -ENOENT) {
> > + memset(rcb->buf, 0, rcb->segsize);
> > + if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else if (r< 0) {
> > + acb->ret = r;
> > + acb->error = 1;
> > + } else if (r< rcb->segsize) {
> > + memset(rcb->buf + r, 0, rcb->segsize - r);
> > + if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else if (!acb->error) {
> > + acb->ret += r;
> > + }
> > + }
> > + if (write(acb->s->efd,&buf, sizeof(buf))< 0)
> > This will wake up the io_read()
> >
> > + error_report("failed writing to acb->s->efd\n");
> > + qemu_free(rcb);
> > + i = 0;
> > + if (!acb->aiocnt&& acb->bh) {
> > + qemu_bh_schedule(acb->bh);
> > This is the only qemu related call in here, seems safe to call it.
> >
> > + }
> > +}
> >
> > The scheduled bh function will be called only after all aios that
> > relate to this specific aio set are done, so the following seems ok,
> > as there's no more acb references.
> > +static void rbd_aio_bh_cb(void *opaque)
> > +{
> > + RBDAIOCB *acb = opaque;
> > + uint64_t buf = 1;
> > +
> > + if (!acb->write) {
> > + qemu_iovec_from_buffer(acb->qiov, acb->bounce, acb->qiov->size);
> > + }
> > + qemu_vfree(acb->bounce);
> > + acb->common.cb(acb->common.opaque, (acb->ret> 0 ? 0 : acb->ret));
> > + qemu_bh_delete(acb->bh);
> > + acb->bh = NULL;
> > +
> > + if (write(acb->s->efd,&buf, sizeof(buf))< 0)
> > + error_report("failed writing to acb->s->efd\n");
> > + qemu_aio_release(acb);
> > +}
> >
> > Now, the second ones are the io_read(), in which we have our glue fd.
> > We send uint64 per each completed io
> >
> > +static void rbd_aio_completion_cb(void *opaque)
> > +{
> > + BDRVRBDState *s = opaque;
> > +
> > + uint64_t val;
> > + ssize_t ret;
> > +
> > + do {
> > + if ((ret = read(s->efd,&val, sizeof(val)))> 0) {
> > + s->qemu_aio_count -= val;
> > There is an issue here with s->qemu_aio_count which needs to be
> > protected by a mutex. Other than that, it just reads from s->efd.
> >
> > + }
> > + } while (ret< 0&& errno == EINTR);
> > +
> > + return;
> > +}
> > +
> > +static int rbd_aio_flush_cb(void *opaque)
> > +{
> > + BDRVRBDState *s = opaque;
> > +
> > + return (s->qemu_aio_count> 0);
> > Same here as with the previous one, needs a mutex around s->qemu_aio_count.
> >
> > +}
> >
> >
> > > If you saw lock ups, I bet that's what it was from.
> > >
> > >
> > As I explained before, before introducing the fd glue layer, the lack
> > of fd associated with our block device caused that there was no way
> > for qemu to check whether all aios were flushed or not, which didn't
> > work well when doing migration/savevm.
> >
> > Thanks,
> > Yehuda
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" 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] SGI Altix IA64 mmtimer: Eliminate long interval timer
From: Andrew Morton @ 2010-10-07 22:42 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20101007143941.GA10653@sgi.com>
On Thu, 7 Oct 2010 09:39:41 -0500
Dimitri Sivanich <sivanich@sgi.com> wrote:
> This patch for SGI Altix/IA64 eliminates interval long timer holdoffs in
> cases where we don't start an interval timer before the expiration time.
> This sometimes happens when a number of interval timers on the same shub
> with the same interval run simultaneously.
>
Grumble.
> --- linux-2.6.orig/drivers/char/mmtimer.c 2010-10-07 09:34:29.837725250 -0500
> +++ linux-2.6/drivers/char/mmtimer.c 2010-10-07 09:34:31.609948769 -0500
> @@ -174,9 +174,8 @@ static void mmtimer_setup_int_2(int cpu,
> * in order to insure that the setup succeeds in a deterministic time frame.
> * It will check if the interrupt setup succeeded.
> */
> -static int mmtimer_setup(int cpu, int comparator, unsigned long expires)
> +static int mmtimer_setup(int cpu, int comparator, unsigned long expires, u64 *r)
Choosing a variable's identifier is your last chance to explain to the
reader what that variable does. And you blew it!
>
> ...
>
> +static unsigned mmtimer_intrvl_retry_incr = MMTIMER_INTRVL_RETRY_INCR_DEFAULT;
> +module_param(mmtimer_intrvl_retry_incr, uint, 0644);
> +MODULE_PARM_DESC(mmtimer_intrvl_retry_incr,
> + "RTC ticks to add to expiration on interval retry (default 40)");
And the problem with abbreviations like "intrvl" is that they're hard
to remember. Which is why in the kernel we much prefer to use the
entire English word.
I'm unable to work out how important this patch is. I'm presently
assuming 2.6.37.
^ permalink raw reply
* Re: g_ether broken on musb
From: Gadiyar, Anand @ 2010-10-07 22:42 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Ming Lei, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi
In-Reply-To: <AANLkTi=gw7EzLdhBPrLkraRtuRiE5e9oUC5LOxGHfReU-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 8, 2010 at 4:07 AM, Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Looks like the transfers get mixed somehow? Curiously after replugging
>>> the cable several times it starts working properly, however the
>>> problem comes back reliably after each reboot.
>>
>> Please apply the patch below against -next tree to see if
>> your issue can be fixed:
>>
>> http://marc.info/?l=linux-usb&m=128576494214316&w=2
>>
>
> Doesn't seem to help:
> # ping pnd
> PING pnd (10.0.1.2) 56(84) bytes of data.
> 64 bytes from pnd (10.0.1.2): icmp_seq=3 ttl=64 time=3000 ms
> 64 bytes from pnd (10.0.1.2): icmp_seq=2 ttl=64 time=5000 ms
> 64 bytes from pnd (10.0.1.2): icmp_seq=1 ttl=64 time=7007 ms
> 64 bytes from pnd (10.0.1.2): icmp_seq=9 ttl=64 time=0.135 ms
> 64 bytes from pnd (10.0.1.2): icmp_seq=11 ttl=64 time=2000 ms
> 64 bytes from pnd (10.0.1.2): icmp_seq=10 ttl=64 time=4000 ms
Can you turn on CONFIG_USB_MUSB_DEBUG, and pass
musb_hdrc.debug=5 in the bootargs?
This should give sufficiently detailed debug messages in the
kernel logs (warning - it slows things down a lot, and could
make the original issue disappear). Maybe these logs
will help identify the problem.
- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* GET BACK TO ME ASAP
From: BARR CHEN SHULIN @ 2010-10-07 22:37 UTC (permalink / raw)
I am Chen Shulin, an attorney at law. A deceased client of mine,
that shares the same last name as yours, died as the result of
a heart-related condition on March 12th 2005. His heart condition
was due to the death of all the members of his family
in the tsunami disaster on the 26th December 2004 in Sumatra Indonesia. http://
en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake
I contacted you to assist in distributing the money left behind by my client(S$17,500,000.00 Million) left behind.Get back to me for more information
Best regards,
Barr.Chen Shulin
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23@cam.ac.uk, joe@perches.com, Andrew Chew, olof@lixom.net,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, Laxman Dewangan
In-Reply-To: <20101007214137.GA9269@kroah.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2693 bytes --]
Sorry resending new patch (compiles fine for me).
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, October 07, 2010 2:42 PM
> To: Rhyland Klein
> Cc: jic23@cam.ac.uk; joe@perches.com; Andrew Chew; olof@lixom.net; linux-
> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> iio@vger.kernel.org; Laxman Dewangan
> Subject: Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
>
> On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> > From: Rhyland Klein <rklein@nvidia.com>
> >
> > adding support for the ISL 29018 ambient light and proximity sensor.
> >
> > Addressed comments from reviews by Jonathan Cameron and Joe Perches
> > * Removed some excess dbg prints that only printed function name
> > * Renamed some properties to make them more descriptive
> > * Added a property to list available adc resolutions
> > * Defined arrays for resolutions/ranges as static const
> > * Change loops initialization to memset for extensibility.
> > * used sizeof() instead of ARRAY_SIZE() to be safer
> > * Added a property to list available adc ranges
> >
> > Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> > Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Too bad no one actually compiled this driver:
> CC [M] drivers/staging/iio/light/isl29018.o
> drivers/staging/iio/light/isl29018.c:420:8: error:
> ‘show_prox_infrared_suppression’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:433:1: error:
> ‘iio_dev_attr_range_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:435:1: error:
> ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
> drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
> drivers/staging/iio/light/isl29018.c: At top level:
> drivers/staging/iio/light/isl29018.c:350:16: warning:
> ‘show_prox_infrared_supression’ defined but not used
> drivers/staging/iio/light/isl29018.c:416:1: warning:
> ‘iio_const_attr_range_available’ defined but not used
> drivers/staging/iio/light/isl29018.c:417:1: warning:
> ‘iio_const_attr_adc_resolution_available’ defined but not used
> make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
> make[1]: *** [drivers/staging/iio/light] Error 2
> make: *** [_module_drivers/staging/iio] Error 2
>
> Please fix this up before resending it.
>
> thanks,
>
> greg k-h
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: twl4030 irq crashes
From: Grazvydas Ignotas @ 2010-10-07 22:40 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <alpine.LFD.2.00.1010072037010.2501@localhost6.localdomain6>
On Thu, Oct 7, 2010 at 9:37 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
>> On Thu, Oct 7, 2010 at 1:59 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
>> >
>> >> Hello,
>> >>
>> >> I've pulled today's (20101006) linux-next and twl4030 started crashing
>> >> on certain interrupts. twl4030 irq code hasn't changed so it's
>> >> probably genirq's fault:
>> >>
>> >> [ 0.889739] Unable to handle kernel NULL pointer dereference at
>> >> virtual address 00000000
>> >> [ 0.898193] pgd = c0004000
>> >> [ 0.901000] [00000000] *pgd=00000000
>> >> [ 0.904754] Internal error: Oops: 80000005 [#1]
>> >> [ 0.909484] last sysfs file:
>> >> [ 0.912567] Modules linked in:
>> >> [ 0.915771] CPU: 0 Not tainted
>> >> (2.6.36-rc6-next-20101006-00001-g766a681-dirty #205)
>> >> [ 0.924133] PC is at 0x0
>> >> [ 0.926788] LR is at handle_edge_irq+0x84/0x14c
>> >
>> > Can you please decode that line with
>> >
>> > addr2line -e vmlinux c0077244
>>
>> kernel/irq/chip.c:725
>
> The patch below should cure that.
Yup, it indeed does.
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
>
> Thanks,
>
> tglx
> ---
> diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
> index 61c8664..b9fda70 100644
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/drivers/mfd/twl4030-irq.c
> @@ -810,7 +810,7 @@ int twl4030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
> twl4030_irq_chip = dummy_irq_chip;
> twl4030_irq_chip.name = "twl4030";
>
> - twl4030_sih_irq_chip.ack = dummy_irq_chip.ack;
> + twl4030_sih_irq_chip.irq_ack = dummy_irq_chip.irq_ack;
>
> for (i = irq_base; i < irq_end; i++) {
> set_irq_chip_and_handler(i, &twl4030_irq_chip,
>
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23@cam.ac.uk, joe@perches.com, Andrew Chew, olof@lixom.net,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, Laxman Dewangan
In-Reply-To: <20101007214137.GA9269@kroah.com>
U29ycnkgcmVzZW5kaW5nIG5ldyBwYXRjaCAoY29tcGlsZXMgZmluZSBmb3IgbWUpLg0KDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdyZWcgS0ggW21haWx0bzpncmVnQGty
b2FoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDcsIDIwMTAgMjo0MiBQTQ0KPiBU
bzogUmh5bGFuZCBLbGVpbg0KPiBDYzogamljMjNAY2FtLmFjLnVrOyBqb2VAcGVyY2hlcy5jb207
IEFuZHJldyBDaGV3OyBvbG9mQGxpeG9tLm5ldDsgbGludXgtDQo+IGkyY0B2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBpaW9Admdlci5rZXJu
ZWwub3JnOyBMYXhtYW4gRGV3YW5nYW4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NV0gc3RhZ2lu
ZzogaWlvOiBsaWdodDogQWRkaW5nIGRyaXZlciBmb3IgSVNMMjkwMTggQUxTDQo+IA0KPiBPbiBU
aHUsIE9jdCAwNywgMjAxMCBhdCAxMjo0ODowM1BNIC0wNzAwLCBya2xlaW5AbnZpZGlhLmNvbSB3
cm90ZToNCj4gPiBGcm9tOiBSaHlsYW5kIEtsZWluIDxya2xlaW5AbnZpZGlhLmNvbT4NCj4gPg0K
PiA+IGFkZGluZyBzdXBwb3J0IGZvciB0aGUgSVNMIDI5MDE4IGFtYmllbnQgbGlnaHQgYW5kIHBy
b3hpbWl0eSBzZW5zb3IuDQo+ID4NCj4gPiBBZGRyZXNzZWQgY29tbWVudHMgZnJvbSByZXZpZXdz
IGJ5IEpvbmF0aGFuIENhbWVyb24gYW5kIEpvZSBQZXJjaGVzDQo+ID4gICAqIFJlbW92ZWQgc29t
ZSBleGNlc3MgZGJnIHByaW50cyB0aGF0IG9ubHkgcHJpbnRlZCBmdW5jdGlvbiBuYW1lDQo+ID4g
ICAqIFJlbmFtZWQgc29tZSBwcm9wZXJ0aWVzIHRvIG1ha2UgdGhlbSBtb3JlIGRlc2NyaXB0aXZl
DQo+ID4gICAqIEFkZGVkIGEgcHJvcGVydHkgdG8gbGlzdCBhdmFpbGFibGUgYWRjIHJlc29sdXRp
b25zDQo+ID4gICAqIERlZmluZWQgYXJyYXlzIGZvciByZXNvbHV0aW9ucy9yYW5nZXMgYXMgc3Rh
dGljIGNvbnN0DQo+ID4gICAqIENoYW5nZSBsb29wcyBpbml0aWFsaXphdGlvbiB0byBtZW1zZXQg
Zm9yIGV4dGVuc2liaWxpdHkuDQo+ID4gICAgICogdXNlZCBzaXplb2YoKSBpbnN0ZWFkIG9mIEFS
UkFZX1NJWkUoKSB0byBiZSBzYWZlcg0KPiA+ICAgKiBBZGRlZCBhIHByb3BlcnR5IHRvIGxpc3Qg
YXZhaWxhYmxlIGFkYyByYW5nZXMNCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFJoeWxhbmQgS2xl
aW4gPHJrbGVpbkBudmlkaWEuY29tPg0KPiA+IEFja2VkLWJ5OiBKb25hdGhhbiBDYW1lcm9uIDxq
aWMyM0BjYW0uYWMudWs+DQo+IA0KPiBUb28gYmFkIG5vIG9uZSBhY3R1YWxseSBjb21waWxlZCB0
aGlzIGRyaXZlcjoNCj4gICBDQyBbTV0gIGRyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkw
MTgubw0KPiBkcml2ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDIwOjg6IGVycm9y
Og0KPiDigJhzaG93X3Byb3hfaW5mcmFyZWRfc3VwcHJlc3Npb27igJkgdW5kZWNsYXJlZCBoZXJl
IChub3QgaW4gYSBmdW5jdGlvbikNCj4gZHJpdmVycy9zdGFnaW5nL2lpby9saWdodC9pc2wyOTAx
OC5jOjQzMzoxOiBlcnJvcjoNCj4g4oCYaWlvX2Rldl9hdHRyX3JhbmdlX2F2YWlsYWJsZeKAmSB1
bmRlY2xhcmVkIGhlcmUgKG5vdCBpbiBhIGZ1bmN0aW9uKQ0KPiBkcml2ZXJzL3N0YWdpbmcvaWlv
L2xpZ2h0L2lzbDI5MDE4LmM6NDM1OjE6IGVycm9yOg0KPiDigJhpaW9fZGV2X2F0dHJfYWRjX3Jl
c29sdXRpb25fYXZhaWxhYmxl4oCZIHVuZGVjbGFyZWQgaGVyZSAobm90IGluIGEgZnVuY3Rpb24p
DQo+IGRyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTguYzogSW4gZnVuY3Rpb24g4oCY
aXNsMjkwMThfY2hpcF9pbml04oCZOg0KPiBkcml2ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5
MDE4LmM6NDUxOjY6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSDigJhp4oCZDQo+IGRyaXZlcnMv
c3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTguYzogQXQgdG9wIGxldmVsOg0KPiBkcml2ZXJzL3N0
YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6MzUwOjE2OiB3YXJuaW5nOg0KPiDigJhzaG93X3By
b3hfaW5mcmFyZWRfc3VwcmVzc2lvbuKAmSBkZWZpbmVkIGJ1dCBub3QgdXNlZA0KPiBkcml2ZXJz
L3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDE2OjE6IHdhcm5pbmc6DQo+IOKAmGlpb19j
b25zdF9hdHRyX3JhbmdlX2F2YWlsYWJsZeKAmSBkZWZpbmVkIGJ1dCBub3QgdXNlZA0KPiBkcml2
ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDE3OjE6IHdhcm5pbmc6DQo+IOKAmGlp
b19jb25zdF9hdHRyX2FkY19yZXNvbHV0aW9uX2F2YWlsYWJsZeKAmSBkZWZpbmVkIGJ1dCBub3Qg
dXNlZA0KPiBtYWtlWzJdOiAqKiogW2RyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTgu
b10gRXJyb3IgMQ0KPiBtYWtlWzFdOiAqKiogW2RyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHRdIEVy
cm9yIDINCj4gbWFrZTogKioqIFtfbW9kdWxlX2RyaXZlcnMvc3RhZ2luZy9paW9dIEVycm9yIDIN
Cj4gDQo+IFBsZWFzZSBmaXggdGhpcyB1cCBiZWZvcmUgcmVzZW5kaW5nIGl0Lg0KPiANCj4gdGhh
bmtzLA0KPiANCj4gZ3JlZyBrLWgNCg==
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org,
joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org, Andrew Chew,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Laxman Dewangan
In-Reply-To: <20101007214137.GA9269-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Sorry resending new patch (compiles fine for me).
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, October 07, 2010 2:42 PM
> To: Rhyland Klein
> Cc: jic23@cam.ac.uk; joe@perches.com; Andrew Chew; olof@lixom.net; linux-
> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> iio@vger.kernel.org; Laxman Dewangan
> Subject: Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
>
> On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> > From: Rhyland Klein <rklein@nvidia.com>
> >
> > adding support for the ISL 29018 ambient light and proximity sensor.
> >
> > Addressed comments from reviews by Jonathan Cameron and Joe Perches
> > * Removed some excess dbg prints that only printed function name
> > * Renamed some properties to make them more descriptive
> > * Added a property to list available adc resolutions
> > * Defined arrays for resolutions/ranges as static const
> > * Change loops initialization to memset for extensibility.
> > * used sizeof() instead of ARRAY_SIZE() to be safer
> > * Added a property to list available adc ranges
> >
> > Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> > Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Too bad no one actually compiled this driver:
> CC [M] drivers/staging/iio/light/isl29018.o
> drivers/staging/iio/light/isl29018.c:420:8: error:
> ‘show_prox_infrared_suppression’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:433:1: error:
> ‘iio_dev_attr_range_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:435:1: error:
> ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
> drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
> drivers/staging/iio/light/isl29018.c: At top level:
> drivers/staging/iio/light/isl29018.c:350:16: warning:
> ‘show_prox_infrared_supression’ defined but not used
> drivers/staging/iio/light/isl29018.c:416:1: warning:
> ‘iio_const_attr_range_available’ defined but not used
> drivers/staging/iio/light/isl29018.c:417:1: warning:
> ‘iio_const_attr_adc_resolution_available’ defined but not used
> make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
> make[1]: *** [drivers/staging/iio/light] Error 2
> make: *** [_module_drivers/staging/iio] Error 2
>
> Please fix this up before resending it.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [Ocfs2-devel] odirect hack
From: Mark Fasheh @ 2010-10-07 22:38 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <4CA65C29.7030001@oracle.com>
On Fri, Oct 01, 2010 at 03:09:45PM -0700, Sunil Mushran wrote:
> I was discussing with Joel whether it was time for us to special
> case the odirect hack we've had since day 1. The one that allows
> concurrent odirect writes.
Right.
> I am wondering whether we should allow users control that behavior
> via a mount option. parallel_directio, maybe.
I think that's got a lot of usefulness, so yeah I'd definitely be behind
this. IMHO, we should take the opportunity to clearly define what it means
for the customer too:
"With this, parallel direct I/O from multiple nodes will be allowed. This
increases throughput on some workloads dramatically but at the expense of
inode mtime updates..." etc etc.
--Mark
--
Mark Fasheh
^ permalink raw reply
* [PATCH] Fix autotools to include the necessary M4 files
From: Jason Gunthorpe @ 2010-10-07 22:38 UTC (permalink / raw)
To: Roland Dreier, Linux RDMA list
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
Makefile.am | 1 +
configure.in | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
Roland - This changes the autogen.sh output from:
+ aclocal -I config
+ libtoolize --force --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
+ autoheader
+ automake --foreign --add-missing --copy
+ autoconf
to:
+ aclocal -I config
+ libtoolize --force --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `config'.
libtoolize: copying file `config/libtool.m4'
libtoolize: copying file `config/ltoptions.m4'
libtoolize: copying file `config/ltsugar.m4'
libtoolize: copying file `config/ltversion.m4'
libtoolize: copying file `config/lt~obsolete.m4'
+ autoheader
+ automake --foreign --add-missing --copy
+ autoconf
And fixes various build problems in weird cases. All of the libraries
you maintain need a similar patch. Do you want me to send seperate
patches for all of them?
diff --git a/Makefile.am b/Makefile.am
index 5aa1289..e6a50ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,7 @@ INCLUDES = -I$(srcdir)/include
lib_LTLIBRARIES = src/libibverbs.la
+ACLOCAL_AMFLAGS = -I config
AM_CFLAGS = -g -Wall
src_libibverbs_la_CFLAGS = $(AM_CFLAGS) -DIBV_CONFIG_DIR=\"$(sysconfdir)/libibverbs.d\"
diff --git a/configure.in b/configure.in
index 927c406..cc93e00 100644
--- a/configure.in
+++ b/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibverbs, 1.1.4, general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org)
AC_CONFIG_SRCDIR([src/ibverbs.h])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AC_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(libibverbs, 1.1.4)
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v2] mac80211: fix possible null-pointer dereference
From: Steve deRosier @ 2010-10-07 22:38 UTC (permalink / raw)
To: Christian Lamparter
Cc: John W. Linville, Luis Carlos Cobo, linux-wireless,
Javier Cardona
In-Reply-To: <201009250002.21219.chunkeey@googlemail.com>
On Fri, Sep 24, 2010 at 3:02 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> ---
> anyway here's my new fix (this time RFC). Is there anyone at
> cozybits who can review the logic in the new patch?
>
Christian,
Javier and I reviewed the patch and it definitely fixes a potential
problem and is correct. Furthermore, applied to wireless-testing
head, it passes all of our cases in our test bed.
I think it's good to go.
- Steve
^ permalink raw reply
* Re: kgdb errors with serial console
From: Jason Wessel @ 2010-10-07 22:37 UTC (permalink / raw)
To: Elvis Dowson; +Cc: Linux Kernel Mailing List, Linux OMAP Mailing List
In-Reply-To: <BDD07355-7199-4A2E-8426-F6D43EA5D313@mac.com>
On 10/07/2010 04:47 PM, Elvis Dowson wrote:
> Hi,
> I'm getting the following errors when attempting to use kgdb with the serial console. Any idea how I can resolve this issue?
>
> The correct serial parameters when I use kermit with the target board is
>
> set flow-control off
> set carrier-watch none
> set speed 115200
>
> and it connects correctly.
>
> I'm not sure if the gdb configuration commands for the serial port are sufficient, and if there is a parameter that I am missing here. The host is connected to the target using an FTDI USB to serial converter, so it appears as /dev/ttyUSB0 on the host and as ttyS2 on the target.
>
> # su
> # cd /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel
> # arm-angstrom-linux-gnueabi-gdb
> (gdb) file vmlinux
> Reading symbols from /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel/vmlinux...done.
>
> (gdb) set remotebaud 115200
> (gdb) set remoteflow 0
> (gdb) set debug remote 1
> (gdb) set debug serial 1
>
You don't want to use this one, it just tends to pollute the logs, "set
debug remote 1" should be enough.
> (gdb) target remote /dev/ttyUSB0
>
>
Looks to me like you did not activate the kernel debugger before using
gdb to enter, because the gdb you are using is not going to send the
"sysrq g" sequence.
What you would want to do here is to "echo g > /proc/sysrq-trigger" with
your terminal program, disconnect and then try connecting the debugger
to the kernel. Another option is to use the agent-proxy so you can
have a console connection and a debugger connection.
It would probably also be good to test if the debugger is working at all
on your serial port.
Configure the debugger with:
# echo ttyS2 > /sys/module/kgdboc/parameters/kgdboc
kgdb: Registered I/O driver kgdboc.
# echo g > /proc/sysrq-trigger
SysRq : DEBUG
And now to exit debugger you must blindly and perfectly type
$D#44+
Nothing will be echoed because at this stage the kernel serial polling
driver would just be collecting characters.
After typing that the kernel should return back to the running state and
print something like:
+$OK#9a#
Jason.
> Remote debugging using /dev/ttyUSB0
> Sending packet: $qSupported#37...[
> r +]Ack
> [$][q][S][u][p][p][o][r][t][e][d][#][3][7]Packet received: qSupported
> Packet qSupported (supported-packets) is supported
> warning: unrecognized item "qSupported" in "qSupported" response
> Sending packet: $Hg0#df...[+]Ack
> [$][H][g][0][#][d][f]Packet received: Hg0
> Sending packet: $?#3f...[+]Ack
> [$][?][#][3][f]Packet received: ?
> Sending packet: $Hc-1#09...[+]Ack
> [$][H][c][-][1][#][0][9]Packet received: Hc-1
> Sending packet: $qC#b4...[+]Ack
> [$][q][C][#][b][4]Packet received: qC
> Sending packet: $qAttached#8f...[+]Ack
> [$][q][A][t][t][a][c][h][e][d][#][8][f]Packet received: qAttached
> Packet qAttached (query-attached) is supported
> Sending packet: $qOffsets#4b...[+]Ack
> [$][q][O][f][f][s][\r][\r][\n][e][t][s][#][4][b]Bad checksum, sentsum=0x4b, csum=0x6f, buf=qOffs\r\r\nets
> [-][<Timeout: 2 seconds>]Timed out.
> [-][<Timeout: 2 seconds>]Timed out.
> Ignoring packet error, continuing...
> Malformed response to offset query, qOffs
> ets
> (gdb)
>
>
> Best regards,
>
> Elvis Dowson
>
>
>
^ permalink raw reply
* Re: g_ether broken on musb
From: Grazvydas Ignotas @ 2010-10-07 22:37 UTC (permalink / raw)
To: Ming Lei
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi
In-Reply-To: <AANLkTin0_RR+m5-BArOhWAGhJY4Mvd3mE53nzEK-9YRk-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Looks like the transfers get mixed somehow? Curiously after replugging
>> the cable several times it starts working properly, however the
>> problem comes back reliably after each reboot.
>
> Please apply the patch below against -next tree to see if
> your issue can be fixed:
>
> http://marc.info/?l=linux-usb&m=128576494214316&w=2
>
Doesn't seem to help:
# ping pnd
PING pnd (10.0.1.2) 56(84) bytes of data.
64 bytes from pnd (10.0.1.2): icmp_seq=3 ttl=64 time=3000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=2 ttl=64 time=5000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=1 ttl=64 time=7007 ms
64 bytes from pnd (10.0.1.2): icmp_seq=9 ttl=64 time=0.135 ms
64 bytes from pnd (10.0.1.2): icmp_seq=11 ttl=64 time=2000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=10 ttl=64 time=4000 ms
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Email Notice
From: info@uknl.co.uk @ 2010-10-07 22:06 UTC (permalink / raw)
Congratulations your email have been selected by the UK National Lottery Online Games, for the sum payout of (£500,000.00) British Pounds For the National Lottery International programs
held this year 2010 in the London United Kingdom promotion.
==============
Payment-Release-Claiming-form
==============
1. Name in Full
2. Address
3. Nationality
4. Age
5. Sex
6. Occupation
7. Phone/Fax
8. Present Country
Contact For Award Recipient.
Mr. Graham Wilbert.
Email: uknl_mr.grahamwilbert@live.co.uk
Regards
Notification department
^ permalink raw reply
* + gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch added to -mm tree
From: akpm @ 2010-10-07 22:34 UTC (permalink / raw)
To: mm-commits; +Cc: tomas.hallenberg, richard.rojfors
The patch titled
gpio: timbgpio: use a copy of the IER register to avoid it being trashed
has been added to the -mm tree. Its filename is
gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: gpio: timbgpio: use a copy of the IER register to avoid it being trashed
From: Tomas Hallenberg <tomas.hallenberg@pelagicore.com>
Some versions of the hardware can trash the IER register if simultaneous
interrupts occur. This patch works around it by using a local copy of the
register and restoring it after every interrupt.
Signed-off-by: Tomas Hallenberg <tomas.hallenberg@pelagicore.com>
Acked-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpio/timbgpio.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff -puN drivers/gpio/timbgpio.c~gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed drivers/gpio/timbgpio.c
--- a/drivers/gpio/timbgpio.c~gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed
+++ a/drivers/gpio/timbgpio.c
@@ -47,6 +47,7 @@ struct timbgpio {
spinlock_t lock; /* mutual exclusion */
struct gpio_chip gpio;
int irq_base;
+ unsigned long last_ier;
};
static int timbgpio_update_bit(struct gpio_chip *gpio, unsigned index,
@@ -112,16 +113,24 @@ static void timbgpio_irq_disable(unsigne
{
struct timbgpio *tgpio = get_irq_chip_data(irq);
int offset = irq - tgpio->irq_base;
+ unsigned long flags;
- timbgpio_update_bit(&tgpio->gpio, offset, TGPIO_IER, 0);
+ spin_lock_irqsave(&tgpio->lock, flags);
+ tgpio->last_ier &= ~(1 << offset);
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
+ spin_unlock_irqrestore(&tgpio->lock, flags);
}
static void timbgpio_irq_enable(unsigned irq)
{
struct timbgpio *tgpio = get_irq_chip_data(irq);
int offset = irq - tgpio->irq_base;
+ unsigned long flags;
- timbgpio_update_bit(&tgpio->gpio, offset, TGPIO_IER, 1);
+ spin_lock_irqsave(&tgpio->lock, flags);
+ tgpio->last_ier |= 1 << offset;
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
+ spin_unlock_irqrestore(&tgpio->lock, flags);
}
static int timbgpio_irq_type(unsigned irq, unsigned trigger)
@@ -194,8 +203,16 @@ static void timbgpio_irq(unsigned int ir
ipr = ioread32(tgpio->membase + TGPIO_IPR);
iowrite32(ipr, tgpio->membase + TGPIO_ICR);
+ /*
+ * Some versions of the hardware trash the IER register if more than
+ * one interrupt is received simultaneously.
+ */
+ iowrite32(0, tgpio->membase + TGPIO_IER);
+
for_each_set_bit(offset, &ipr, tgpio->gpio.ngpio)
generic_handle_irq(timbgpio_to_irq(&tgpio->gpio, offset));
+
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
}
static struct irq_chip timbgpio_irqchip = {
_
Patches currently in -mm which might be from tomas.hallenberg@pelagicore.com are
gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" 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
* [Bug 30693] [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-07 22:34 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30693-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30693
--- Comment #1 from darkbasic <darkbasic4@gmail.com> 2010-10-07 15:34:36 PDT ---
I forgot to mention I use xorg 1.9.901.
--
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
* [Bug 30693] New: [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-07 22:34 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=30693
Summary: [R600c KWin 4.5.2] Blur does not work with RV670 (it
works with RV710)
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: darkbasic4@gmail.com
Created an attachment (id=39272)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39272)
Blur not working
Hi, with 2.6.36-rc7|drm-radeon-testing and latest graphic stack snapshot kwin's
4.5.2 blur effect does not work. I have an HD3870, but someone else told me it
works with RV710 (http://www.phoronix.com/forums/showthread.php?t=26221).
I attached a screenshot.
--
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 management.git] Fix autotools to include the necessary M4 files
From: Jason Gunthorpe @ 2010-10-07 22:33 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Linux RDMA list
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
infiniband-diags/Makefile.am | 1 +
infiniband-diags/configure.in | 1 +
libibmad/Makefile.am | 2 +-
libibmad/configure.in | 1 +
libibumad/Makefile.am | 2 +-
libibumad/configure.in | 1 +
opensm/configure.in | 1 +
7 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/infiniband-diags/Makefile.am b/infiniband-diags/Makefile.am
index af90b05..e4d3d90 100644
--- a/infiniband-diags/Makefile.am
+++ b/infiniband-diags/Makefile.am
@@ -1,3 +1,4 @@
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = libibnetdisc
INCLUDES = -I$(top_builddir)/include/ -I$(srcdir)/include -I$(includedir) \
diff --git a/infiniband-diags/configure.in b/infiniband-diags/configure.in
index b9326c0..3c16aec 100644
--- a/infiniband-diags/configure.in
+++ b/infiniband-diags/configure.in
@@ -3,6 +3,7 @@ dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.57)
AC_INIT(infiniband-diags, 1.5.7, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/libibmad/Makefile.am b/libibmad/Makefile.am
index 6881453..f732c6c 100644
--- a/libibmad/Makefile.am
+++ b/libibmad/Makefile.am
@@ -1,4 +1,4 @@
-
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = .
INCLUDES = -I$(srcdir)/include -I$(includedir)
diff --git a/libibmad/configure.in b/libibmad/configure.in
index 23ec914..97e8cb3 100644
--- a/libibmad/configure.in
+++ b/libibmad/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibmad, 1.3.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([src/sa.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/libibumad/Makefile.am b/libibumad/Makefile.am
index 6e3f518..28bf69c 100644
--- a/libibumad/Makefile.am
+++ b/libibumad/Makefile.am
@@ -1,4 +1,4 @@
-
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = .
INCLUDES = -I$(srcdir)/include/infiniband -I$(includedir)
diff --git a/libibumad/configure.in b/libibumad/configure.in
index 9fcd609..04ecb0e 100644
--- a/libibumad/configure.in
+++ b/libibumad/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibumad, 1.3.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([src/umad.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/opensm/configure.in b/opensm/configure.in
index 8695965..057724a 100644
--- a/opensm/configure.in
+++ b/opensm/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(opensm, 3.3.7, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([opensm/osm_opensm.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AC_CONFIG_HEADERS(include/config.h include/opensm/osm_config.h)
AM_INIT_AUTOMAKE
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [Bug 16140] Suspend To RAM/ Resume broken - Radeon KMS on RV250
From: bugzilla-daemon @ 2010-10-07 22:32 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-16140-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=16140
--- Comment #22 from Florian Mickler <florian@mickler.org> 2010-10-07 22:32:46 ---
(In reply to comment #20)
> You can't read?
I wondered that myself...
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* [Bug 16140] Suspend To RAM/ Resume broken - Radeon KMS on RV250
From: bugzilla-daemon @ 2010-10-07 22:31 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-16140-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=16140
--- Comment #21 from Florian Mickler <florian@mickler.org> 2010-10-07 22:31:27 ---
Created an attachment (id=32762)
--> (https://bugzilla.kernel.org/attachment.cgi?id=32762)
debug patch to see where we fail to set up the ring
You have this in you kern.log file:
[drm] radeon: ring at 0x00000000D0000000
which doesnt't look so good.
>From there on it goes bad:
Sep 17 13:12:12 tbox kernel: [ 381.304184] [drm:r100_ring_test] *ERROR*
radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
Sep 17 13:12:12 tbox kernel: [ 381.304187] [drm:r100_cp_init] *ERROR* radeon:
cp isn't working (-22).
Sep 17 13:12:12 tbox kernel: [ 381.304191] radeon 0000:01:00.0: failled
initializing CP (-22).
which explains the
"[drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(0)." message.
cp.ready is false, due to r100_cp_init failing.
Let's see if we can narrow down what fails. Can you apply this patch and post
the resulting kern.log?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* [PATCH] kvm_monitor.py: is_responsive(): Use status command
From: Luiz Capitulino @ 2010-10-07 22:30 UTC (permalink / raw)
To: autotest; +Cc: kvm, lmr, ehabkost
The is_responsive() method in QMPMonitor class uses the query-version
command to check if the monitor is alive and the same method in the
HumanMonitor class uses the help command.
This commit changes both classes to use the status command instead,
so that:
o The QEMU's response is shorter when using the Human Monitor. The
help command output is 70 lines long, which makes it a bit
expansive for a single ping
o is_responsive() can be extended to check if QEMU is running
o My logs won't be flooded with help's output :-)
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
client/tests/kvm/kvm_monitor.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/client/tests/kvm/kvm_monitor.py b/client/tests/kvm/kvm_monitor.py
index 9a66388..8c92413 100644
--- a/client/tests/kvm/kvm_monitor.py
+++ b/client/tests/kvm/kvm_monitor.py
@@ -243,7 +243,7 @@ class HumanMonitor(Monitor):
@return: True if responsive, False otherwise
"""
try:
- self._get_command_output("help")
+ self._get_command_output("info status")
return True
except MonitorError:
return False
@@ -548,7 +548,7 @@ class QMPMonitor(Monitor):
@return: True if responsive, False otherwise
"""
try:
- self._get_command_output("query-version")
+ self._get_command_output("query-status")
return True
except MonitorError:
return False
--
1.7.3.1.104.gc752e
^ permalink raw reply related
* + sysctl-min-max-bounds-are-optional.patch added to -mm tree
From: akpm @ 2010-10-07 22:28 UTC (permalink / raw)
To: mm-commits; +Cc: eric.dumazet, davem, ebiederm, jirislaby
The patch titled
sysctl: min/max bounds are optional
has been added to the -mm tree. Its filename is
sysctl-min-max-bounds-are-optional.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: sysctl: min/max bounds are optional
From: Eric Dumazet <eric.dumazet@gmail.com>
sysctl check complains when proc_doulongvec_minmax or
proc_doulongvec_ms_jiffies_minmax are used by a vector of longs (with more
than one element), with no min or max value specified.
This is unexpected, given we had a bug on this min/max handling :)
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sysctl_check.c | 9 ---------
1 file changed, 9 deletions(-)
diff -puN kernel/sysctl_check.c~sysctl-min-max-bounds-are-optional kernel/sysctl_check.c
--- a/kernel/sysctl_check.c~sysctl-min-max-bounds-are-optional
+++ a/kernel/sysctl_check.c
@@ -143,15 +143,6 @@ int sysctl_check_table(struct nsproxy *n
if (!table->maxlen)
set_fail(&fail, table, "No maxlen");
}
- if ((table->proc_handler == proc_doulongvec_minmax) ||
- (table->proc_handler == proc_doulongvec_ms_jiffies_minmax)) {
- if (table->maxlen > sizeof (unsigned long)) {
- if (!table->extra1)
- set_fail(&fail, table, "No min");
- if (!table->extra2)
- set_fail(&fail, table, "No max");
- }
- }
#ifdef CONFIG_PROC_SYSCTL
if (table->procname && !table->proc_handler)
set_fail(&fail, table, "No proc_handler");
_
Patches currently in -mm which might be from eric.dumazet@gmail.com are
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
sysctl-min-max-bounds-are-optional.patch
linux-next.patch
net-avoid-limits-overflow.patch
fs-allow-for-more-than-231-files.patch
percpu_counter-use-this_cpu_ptr-instead-of-per_cpu_ptr.patch
signals-annotate-lock_task_sighand.patch
^ permalink raw reply
* Re: IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Andrew Morton @ 2010-10-07 22:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jiri Slaby, linux-kernel, mm-commits, ML netdev, David S. Miller,
Eric W. Biederman
In-Reply-To: <1286490135.6536.75.camel@edumazet-laptop>
On Fri, 08 Oct 2010 00:22:15 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 08 octobre 2010 __ 00:06 +0200, Jiri Slaby a __crit :
> > On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> > > The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
> >
> > Hi, I got bunch of "sysctl table check failed" below. All seem to be
> > related to ipv4:
>
> I would say, sysctl check is buggy :(
>
> min/max are optional
>
> [PATCH] sysctl: min/max bounds are optional
>
> sysctl check complains when proc_doulongvec_minmax or
> proc_doulongvec_ms_jiffies_minmax are used by a vector of longs (with
> more than one element), with no min or max value specified.
>
> This is unexpected, given we had a bug on this min/max handling :)
>
> Reported-by: Jiri Slaby <jirislaby@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> kernel/sysctl_check.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
> index 04cdcf7..10b90d8 100644
> --- a/kernel/sysctl_check.c
> +++ b/kernel/sysctl_check.c
> @@ -143,15 +143,6 @@ int sysctl_check_table(struct nsproxy *namespaces, struct ctl_table *table)
> if (!table->maxlen)
> set_fail(&fail, table, "No maxlen");
> }
> - if ((table->proc_handler == proc_doulongvec_minmax) ||
> - (table->proc_handler == proc_doulongvec_ms_jiffies_minmax)) {
> - if (table->maxlen > sizeof (unsigned long)) {
> - if (!table->extra1)
> - set_fail(&fail, table, "No min");
> - if (!table->extra2)
> - set_fail(&fail, table, "No max");
> - }
> - }
> #ifdef CONFIG_PROC_SYSCTL
> if (table->procname && !table->proc_handler)
> set_fail(&fail, table, "No proc_handler");
That will probably fix it ;)
net-avoid-limits-overflow.patch is dependent on this patch. Unless
Eric B squeaks I'll plan on sending this patch in for 2.6.37.
^ 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.