* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007175358.GD12130@sigill.intra.peff.net>
On Thu, Oct 7, 2010 at 7:53 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:
>
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>
>> > 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.
>>
>> I don't know which one would be most portable, but if fwrite is the
>> problem, then
>>
>> printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
>>
>> should do the trick.
>
> It does work, but you have to cast the buf.len size_t to an int.
>
I'm not sure how portable it is, though. This is what K&R has to say
on the matter: "characters from the string are printed until a ´\0´ is
reached or until the number of characters indicated by the precision
have been printed". To me it's not clear if that means that either
cases can terminate the printing when the precision has been
specified.
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Sameer Nanda @ 2010-10-07 18:05 UTC (permalink / raw)
To: Greg KH; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <20101007174626.GA31541@suse.de>
On Thu, Oct 7, 2010 at 10:46 AM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
>> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
>> > And are you always going to be printing this out? Why do we want to
>> > know this every time?
>> >
>>
>> Yes, every time. This helps track variance in BIOS resume times within a
>> single boot.
>
> Is that really something that users can do something about?
Aside from complaining to the BIOS vendors, no :)
> I can
> understand when you are trying to work with a BIOS company, but
> otherwise, this seems quite pointless.
>
> thanks,
>
> greg k-h
>
--
Sameer
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Sameer Nanda @ 2010-10-07 18:05 UTC (permalink / raw)
To: Greg KH; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <20101007174626.GA31541@suse.de>
On Thu, Oct 7, 2010 at 10:46 AM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
>> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
>> > And are you always going to be printing this out? Why do we want to
>> > know this every time?
>> >
>>
>> Yes, every time. This helps track variance in BIOS resume times within a
>> single boot.
>
> Is that really something that users can do something about?
Aside from complaining to the BIOS vendors, no :)
> I can
> understand when you are trying to work with a BIOS company, but
> otherwise, this seems quite pointless.
>
> thanks,
>
> greg k-h
>
--
Sameer
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 13/15] cifs: convert cifsFileInfo->count to non-atomic counter
From: Christoph Hellwig @ 2010-10-07 18:05 UTC (permalink / raw)
To: Steve French
Cc: Jeff Layton, Suresh Jayaraman, linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTi=MMzU6nr6+19PKW=gPKTdk9e-O5pjrYWmbV4AJ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Oct 07, 2010 at 10:37:54AM -0500, Steve French wrote:
>
> I doubt that a spinlock vs. a rwlock makes much difference,
> but a rwlock lock for list insertion/removal seems more intuitive
> and overloading it to also protect a counter adds complexity.
> Seems more natural to leave it as an atomic counter.
The rwlock here is rather non-sensical. A shared/exclusie lock only
makes sense if the critical section is large enough to actually
benefit from concurrency. With a short critical section like here
you still pay the same price in terms of cache line effects, and
operations on rwlocks actually are more expensive than on a normal
spinlock. We don't actually hae a lot of places where the plain
rwlock makes any sense at all - if there's enough reason for concurreny
you're better off doing RCU locking anyway.
^ permalink raw reply
* Re: pvops Dom0 graphics doesnt work with Intel i915
From: Konrad Rzeszutek Wilk @ 2010-10-07 18:05 UTC (permalink / raw)
To: sanjay kushwaha; +Cc: Jeremy Fitzhardinge, xen-devel
In-Reply-To: <AANLkTim4Dw0LtSFVjn+7bR7OXrR7+UgyM6OPzDXwqaD-@mail.gmail.com>
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
^ permalink raw reply
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Gleb Natapov @ 2010-10-07 18:03 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CAE00CB.1070400@redhat.com>
On Thu, Oct 07, 2010 at 07:18:03PM +0200, Avi Kivity wrote:
> On 10/07/2010 07:14 PM, Gleb Natapov wrote:
> >On Thu, Oct 07, 2010 at 03:10:27PM +0200, Avi Kivity wrote:
> >> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >> >When async PF capability is detected hook up special page fault handler
> >> >that will handle async page fault events and bypass other page faults to
> >> >regular page fault handler. Also add async PF handling to nested SVM
> >> >emulation. Async PF always generates exit to L1 where vcpu thread will
> >> >be scheduled out until page is available.
> >> >
> >>
> >> Please separate guest and host changes.
> >>
> >> >+void kvm_async_pf_task_wait(u32 token)
> >> >+{
> >> >+ u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS);
> >> >+ struct kvm_task_sleep_head *b =&async_pf_sleepers[key];
> >> >+ struct kvm_task_sleep_node n, *e;
> >> >+ DEFINE_WAIT(wait);
> >> >+
> >> >+ spin_lock(&b->lock);
> >> >+ e = _find_apf_task(b, token);
> >> >+ if (e) {
> >> >+ /* dummy entry exist -> wake up was delivered ahead of PF */
> >> >+ hlist_del(&e->link);
> >> >+ kfree(e);
> >> >+ spin_unlock(&b->lock);
> >> >+ return;
> >> >+ }
> >> >+
> >> >+ n.token = token;
> >> >+ n.cpu = smp_processor_id();
> >> >+ init_waitqueue_head(&n.wq);
> >> >+ hlist_add_head(&n.link,&b->list);
> >> >+ spin_unlock(&b->lock);
> >> >+
> >> >+ for (;;) {
> >> >+ prepare_to_wait(&n.wq,&wait, TASK_UNINTERRUPTIBLE);
> >> >+ if (hlist_unhashed(&n.link))
> >> >+ break;
> >> >+ local_irq_enable();
> >>
> >> Suppose we take another apf here. And another, and another (for
> >> different pages, while executing schedule()). What's to prevent
> >> kernel stack overflow?
> >>
> >Host side keeps track of outstanding apfs and will not send apf for the
> >same phys address twice. It will halt vcpu instead.
>
> What about different pages, running the scheduler code?
>
We can get couple of nested apfs, just like we can get nested
interrupts. Since scheduler disables preemption second apf will halt.
> Oh, and we'll run the scheduler recursively.
>
As rick said scheduler disables preemption. And this is actually first
thing it does. Otherwise any interrupt may cause recursive scheduler
invocation.
--
Gleb.
^ permalink raw reply
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
From: Wolfgang Denk @ 2010-10-07 18:04 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=usuEyf4YuUVWrrLu80bMRFpRF+BThEix2bFNg@mail.gmail.com>
Dear chris c,
In message <AANLkTi=usuEyf4YuUVWrrLu80bMRFpRF+BThEix2bFNg@mail.gmail.com> you wrote:
>
> I was comparing time just by timing it manually. How did you instrument
> u-boot to display the time?
That's no instrumentation of U-Boot, but just timestamping the output
on the serial console. See for example
ftp://ftp.denx.de/pub/tools/time_log
> As for the small versus large file, I did the same test for 1MB of data
> using nand read and saw a x4 performance advantage. I also did a test on
> mmc with 100 MB file and saw no performance increase. Looks like file size
> doesn't matter.
>
> So does that mean that MMC file loading will not benefit from dcache
> enabled? Can anybody explain this?
It depends on where the time is actually spent. If you have a slow
(say, bit-banging) MMC driver and a low-performance CPU then the
transfer from MMC might simply not depend as much on caches. It is
wrong to check just a simple use case. Try a number of different
operations, like umcompressing a large image in RAM or from NOR to
RAM, or downloading over the net, or ...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is
not music; Music is the best." - Frank Zappa
^ permalink raw reply
* Re: [PATCH v6 08/12] Handle async PF in a guest.
From: Gleb Natapov @ 2010-10-07 18:03 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CAE00CB.1070400@redhat.com>
On Thu, Oct 07, 2010 at 07:18:03PM +0200, Avi Kivity wrote:
> On 10/07/2010 07:14 PM, Gleb Natapov wrote:
> >On Thu, Oct 07, 2010 at 03:10:27PM +0200, Avi Kivity wrote:
> >> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >> >When async PF capability is detected hook up special page fault handler
> >> >that will handle async page fault events and bypass other page faults to
> >> >regular page fault handler. Also add async PF handling to nested SVM
> >> >emulation. Async PF always generates exit to L1 where vcpu thread will
> >> >be scheduled out until page is available.
> >> >
> >>
> >> Please separate guest and host changes.
> >>
> >> >+void kvm_async_pf_task_wait(u32 token)
> >> >+{
> >> >+ u32 key = hash_32(token, KVM_TASK_SLEEP_HASHBITS);
> >> >+ struct kvm_task_sleep_head *b =&async_pf_sleepers[key];
> >> >+ struct kvm_task_sleep_node n, *e;
> >> >+ DEFINE_WAIT(wait);
> >> >+
> >> >+ spin_lock(&b->lock);
> >> >+ e = _find_apf_task(b, token);
> >> >+ if (e) {
> >> >+ /* dummy entry exist -> wake up was delivered ahead of PF */
> >> >+ hlist_del(&e->link);
> >> >+ kfree(e);
> >> >+ spin_unlock(&b->lock);
> >> >+ return;
> >> >+ }
> >> >+
> >> >+ n.token = token;
> >> >+ n.cpu = smp_processor_id();
> >> >+ init_waitqueue_head(&n.wq);
> >> >+ hlist_add_head(&n.link,&b->list);
> >> >+ spin_unlock(&b->lock);
> >> >+
> >> >+ for (;;) {
> >> >+ prepare_to_wait(&n.wq,&wait, TASK_UNINTERRUPTIBLE);
> >> >+ if (hlist_unhashed(&n.link))
> >> >+ break;
> >> >+ local_irq_enable();
> >>
> >> Suppose we take another apf here. And another, and another (for
> >> different pages, while executing schedule()). What's to prevent
> >> kernel stack overflow?
> >>
> >Host side keeps track of outstanding apfs and will not send apf for the
> >same phys address twice. It will halt vcpu instead.
>
> What about different pages, running the scheduler code?
>
We can get couple of nested apfs, just like we can get nested
interrupts. Since scheduler disables preemption second apf will halt.
> Oh, and we'll run the scheduler recursively.
>
As rick said scheduler disables preemption. And this is actually first
thing it does. Otherwise any interrupt may cause recursive scheduler
invocation.
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Drew Northup @ 2010-10-07 18:02 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <vpqy6a952bh.fsf@bauges.imag.fr>
On Thu, 2010-10-07 at 19:40 +0200, Matthieu Moy wrote:
> 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.
Agreed. I could have sworn that printf() used standard C-strings which
terminate with %x00!
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: NIC limit
From: linux_kvm @ 2010-10-07 18:03 UTC (permalink / raw)
To: Chris Wright
In-Reply-To: <20101006171817.GE18885@sequoia.sous-sol.org>
>The PCI bus has only 32 slots (devices), 3 taken by chipset + vga, and
>a 4th if you have, for example, a virtio disk. Are you sure these are
>33 PCI devices and not 33 PCI functions?
No, not sure.
Apparently my statement was based on an uninformed assumption.
I tested using a VM that had 30 (removable-per-web-interface)
attachments, and added 3x IDE HDDs to bring it above what I thought was
32 devices:
28 virtio NICs
1 IDE CD-ROM
1 virtio HDD
+3 IDE HDDs
I could add IDE up past 32 and it would start, as soon as there were
more than 28 NICs with or without the 3 IDE HDDs, start would fail.
On Wed, 06 Oct 2010 10:18 -0700, "Chris Wright" <chrisw@sous-sol.org>
wrote:
> * linux_kvm@proinbox.com (linux_kvm@proinbox.com) wrote:
> > Hi again everybody,
> >
> > One of the admins at the ProxmoxVE project was gracious enough to
> > quickly release a package including the previously discussed change to
> > allow up to 32 NICs in qemu.
>
> You mean they patched qemu to increase the MAX_NICS constant? Nice to
> get the quick turn around.
>
> Te better choice is to use a newer command line. Not only does it avoid
> the MAX_NICS limitation, but it also enables standard virtio-net offload
> accelerations.
>
> > For future reference the .deb is here:
> > ftp://download.proxmox.com/debian/dists/lenny/pvetest/binary-amd64/pve-qemu-kvm_0.12.5-2_amd64.deb
> >
> > Upon creating & running the VM with the newly patched qemu-kvm app
> > installed, I found a NIC limitation remained in place, presumably
> > imposed by some other aspect of the environment.
> >
> > The machine would start when it had 33 PCI devices, as long as no more
> > than 28 of them were NICs.
>
> The PCI bus has only 32 slots (devices), 3 taken by chipset + vga, and
> a 4th if you have, for example, a virtio disk. Are you sure these are
> 33 PCI devices and not 33 PCI functions?
>
> thanks,
> -chris
>
^ permalink raw reply
* [PATCH] Add support for Attribute Write Request
From: Anderson Lizardo @ 2010-10-07 18:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
Implement encoders/decoders for Write Request/Response and the handling
on attribute server. The attribute client still uses the Write Command
because currently SetProperty() has no means to wait for the server
response.
---
attrib/att.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
attrib/att.h | 4 ++++
attrib/gatt.c | 11 +++++++++++
attrib/gatt.h | 3 +++
src/attrib-server.c | 12 +++++++++++-
5 files changed, 79 insertions(+), 1 deletions(-)
diff --git a/attrib/att.c b/attrib/att.c
index 2ffa8ce..fe41d0e 100644
--- a/attrib/att.c
+++ b/attrib/att.c
@@ -363,6 +363,56 @@ uint16_t dec_write_cmd(const uint8_t *pdu, int len, uint16_t *handle,
return len;
}
+uint16_t enc_write_req(uint16_t handle, const uint8_t *value, int vlen,
+ uint8_t *pdu, int len)
+{
+ const uint16_t min_len = sizeof(pdu[0]) + sizeof(handle);
+
+ if (pdu == NULL)
+ return 0;
+
+ if (len < min_len)
+ return 0;
+
+ if (vlen > len - min_len)
+ vlen = len - min_len;
+
+ pdu[0] = ATT_OP_WRITE_REQ;
+ att_put_u16(handle, &pdu[1]);
+
+ if (vlen > 0) {
+ memcpy(&pdu[3], value, vlen);
+ return min_len + vlen;
+ }
+
+ return min_len;
+}
+
+uint16_t dec_write_req(const uint8_t *pdu, int len, uint16_t *handle,
+ uint8_t *value, int *vlen)
+{
+ const uint16_t min_len = sizeof(pdu[0]) + sizeof(*handle);
+
+ if (pdu == NULL)
+ return 0;
+
+ if (value == NULL || vlen == NULL || handle == NULL)
+ return 0;
+
+ if (len < min_len)
+ return 0;
+
+ if (pdu[0] != ATT_OP_WRITE_REQ)
+ return 0;
+
+ *handle = att_get_u16(&pdu[1]);
+ *vlen = len - min_len;
+ if (*vlen > 0)
+ memcpy(value, pdu + min_len, *vlen);
+
+ return len;
+}
+
uint16_t enc_read_req(uint16_t handle, uint8_t *pdu, int len)
{
const uint16_t min_len = sizeof(pdu[0]) + sizeof(handle);
diff --git a/attrib/att.h b/attrib/att.h
index 3913f47..ea49dc2 100644
--- a/attrib/att.h
+++ b/attrib/att.h
@@ -178,6 +178,10 @@ uint16_t enc_write_cmd(uint16_t handle, const uint8_t *value, int vlen,
uint16_t dec_write_cmd(const uint8_t *pdu, int len, uint16_t *handle,
uint8_t *value, int *vlen);
struct att_data_list *dec_read_by_type_resp(const uint8_t *pdu, int len);
+uint16_t enc_write_req(uint16_t handle, const uint8_t *value, int vlen,
+ uint8_t *pdu, int len);
+uint16_t dec_write_req(const uint8_t *pdu, int len, uint16_t *handle,
+ uint8_t *value, int *vlen);
uint16_t enc_read_req(uint16_t handle, uint8_t *pdu, int len);
uint16_t dec_read_req(const uint8_t *pdu, int len, uint16_t *handle);
uint16_t enc_read_resp(uint8_t *value, int vlen, uint8_t *pdu, int len);
diff --git a/attrib/gatt.c b/attrib/gatt.c
index e8171a9..24ec990 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -76,6 +76,17 @@ guint gatt_read_char(GAttrib *attrib, uint16_t handle, GAttribResultFunc func,
user_data, NULL);
}
+guint gatt_write_char(GAttrib *attrib, uint16_t handle, uint8_t *value,
+ int vlen, GAttribResultFunc func, gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_write_req(handle, value, vlen, pdu, sizeof(pdu));
+ return g_attrib_send(attrib, ATT_OP_WRITE_REQ, pdu, plen, func,
+ user_data, NULL);
+}
+
guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
diff --git a/attrib/gatt.h b/attrib/gatt.h
index c99b946..a357f58 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -31,6 +31,9 @@ guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_read_char(GAttrib *attrib, uint16_t handle, GAttribResultFunc func,
gpointer user_data);
+guint gatt_write_char(GAttrib *attrib, uint16_t handle, uint8_t *value,
+ int vlen, GAttribResultFunc func, gpointer user_data);
+
guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data);
diff --git a/src/attrib-server.c b/src/attrib-server.c
index b45f300..666b5fa 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -504,6 +504,17 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
length = find_info(start, end, opdu, channel->mtu);
break;
+ case ATT_OP_WRITE_REQ:
+ length = dec_write_req(ipdu, len, &start, value, &vlen);
+ if (length == 0) {
+ status = ATT_ECODE_INVALID_PDU;
+ goto done;
+ }
+
+ write_value(start, value, vlen);
+ opdu[0] = ATT_OP_WRITE_RESP;
+ length = sizeof(opdu[0]);
+ break;
case ATT_OP_WRITE_CMD:
length = dec_write_cmd(ipdu, len, &start, value, &vlen);
if (length > 0)
@@ -512,7 +523,6 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
case ATT_OP_FIND_BY_TYPE_REQ:
case ATT_OP_READ_BLOB_REQ:
case ATT_OP_READ_MULTI_REQ:
- case ATT_OP_WRITE_REQ:
case ATT_OP_PREP_WRITE_REQ:
case ATT_OP_EXEC_WRITE_REQ:
default:
--
1.7.0.4
^ permalink raw reply related
* linux-scsi on a iSCSI target mode PCIe HBA
From: iscsi learner @ 2010-10-07 18:02 UTC (permalink / raw)
To: linux-scsi
Hi
I have a target mode iSCSI (and linux 2.6.27) running on a PCIe HBA.
This target mode HBA will completely offload iSCSI
from storage server to itself. Storage server will receive only SCSI
CDB (from this PCIe target HBA) and pass it to attached disk backend.
Over the PCIe interface only the SCSI command-response/data is exchanged.
Experts, please clear my doubt about the work/design to make it work-
I think I should register myself as SCSI Mid Layer LLD and then all
the SCSI command/data received by target-mode-iSCSI-stack will be
available in queuecommand interface of SCSI Mid layer. Is that the
right assumption and the best approach?
In my case the LLD will then pass that SCSI command/data across the
PCIe to storage server. To be more clear this LLD will be running
ON a PCIe HBA
The target mode iSCSI stack can be any one of the popular linux iSCSI
target stacks.
Thanks much in advance
^ permalink raw reply
* Re: [PATCH v2 00/11] SDIO Runtime PM Support
From: Chris Ball @ 2010-10-07 18:01 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Ohad Ben-Cohen, Chris Ball, linux-mmc@vger.kernel.org,
linux-wireless@vger.kernel.org, Nicolas Pitre
In-Reply-To: <1286454736.27371.37.camel@chilepepper>
Hi Luciano, Ohad,
On Thu, Oct 07, 2010 at 03:32:16PM +0300, Luciano Coelho wrote:
> I have tested this on my beagle board with the wl1271 patches that Ohad
> provided and it seems to be working fine. I've also created a small
> script to stress test the implementation a little bit and didn't see any
> problems.
>
> Tested-by: Luciano Coelho <luciano.coelho@nokia.com>
>
> This is quite an important fix in the wl1271 point-of-view. Chris, do
> you think there is any chance that this could make it to 2.6.37?
Yes, can do -- the patchset looks good, and I've just pushed patches
1-9 (the MMC patches) to mmc-next. Please go ahead and submit the
two wl1271 patches through wireless-testing whenever you're ready.
Thanks!
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH v2 00/11] SDIO Runtime PM Support
From: Chris Ball @ 2010-10-07 18:01 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Ohad Ben-Cohen, Chris Ball,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nicolas Pitre
In-Reply-To: <1286454736.27371.37.camel@chilepepper>
Hi Luciano, Ohad,
On Thu, Oct 07, 2010 at 03:32:16PM +0300, Luciano Coelho wrote:
> I have tested this on my beagle board with the wl1271 patches that Ohad
> provided and it seems to be working fine. I've also created a small
> script to stress test the implementation a little bit and didn't see any
> problems.
>
> Tested-by: Luciano Coelho <luciano.coelho-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
>
> This is quite an important fix in the wl1271 point-of-view. Chris, do
> you think there is any chance that this could make it to 2.6.37?
Yes, can do -- the patchset looks good, and I've just pushed patches
1-9 (the MMC patches) to mmc-next. Please go ahead and submit the
two wl1271 patches through wireless-testing whenever you're ready.
Thanks!
--
Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org> <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH v6 06/12] Add PV MSR to enable asynchronous page faults delivery.
From: Gleb Natapov @ 2010-10-07 17:59 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC3F2.2050506@redhat.com>
On Thu, Oct 07, 2010 at 02:58:26PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >+
> >+ Physical address points to 32 bit memory location that will be written
> >+ to by the hypervisor at the time of asynchronous page fault injection to
> >+ indicate type of asynchronous page fault. Value of 1 means that the page
> >+ referred to by the page fault is not present. Value 2 means that the
> >+ page is now available.
>
> "The must not enable interrupts before the reason is read, or it may
> be overwritten by another apf".
>
> Document the fact that disabling interrupts disables APFs.
>
> How does the guest distinguish betweem APFs and ordinary page faults?
>
> What's the role of cr2?
>
> When disabling APF, all pending APFs are flushed and may or may not
> get a completion.
>
> Is a "page available" notification guaranteed to arrive on the same
> vcpu that took the "page not present" fault?
>
You mean documentation is lacking? :)
--
Gleb.
^ permalink raw reply
* Re: [PATCH v2] ARM: allow, but warn, when issuing ioremap() on RAM
From: Uwe Kleine-König @ 2010-10-07 18:00 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-main, linux-arm, Laurent Pinchart, Baruch Siach,
Han Jonghun, Hemant Pedanekar, Arnd Hannemann, Omar Ramirez Luna
In-Reply-To: <1286454549-19690-1-git-send-email-felipe.contreras@gmail.com>
Hello,
On Thu, Oct 07, 2010 at 03:29:09PM +0300, Felipe Contreras wrote:
> Many drivers are broken, and there's no alternative in sight. Such a big
> change should stay as a warning for now, and only later should it
> actually fail.
>
> The drivers are not doing something correct, we get it, but for now it's
> better to allow them to work (they do 99% of the time anyway) rather
> than to force everyone to revert this patch in their internal trees
> until there's a solution. A slightly broken functionality is better than
> no functionality at all.
>
> A warning lets people know that what they are doing is not right, and
> they should fix it.
>
> Cc: Han Jonghun <jonghun79.han@gmail.com>
> Cc: Hemant Pedanekar <hemantp@ti.com>
> Cc: Arnd Hannemann <arnd@arndnet.de>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> arch/arm/mm/ioremap.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> For issues related to this:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/84454
> http://article.gmane.org/gmane.linux.ports.sh.devel/8560
> http://www.spinics.net/lists/linux-fbdev/msg01745.html
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/22271
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..a168673 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -202,10 +202,9 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> return NULL;
>
> /*
> - * Don't allow RAM to be mapped - this causes problems with ARMv6+
> + * This causes problems with ARMv6+. Will be disallowed soon.
maybe specify soon as "before 2.6.37"?
Other than that, Acked-by: Uwe Kleine-König
<u.kleine-koenig@pengutronix.de>
because there is no other solution to make it into the kernel before
.36.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] ARM: allow, but warn, when issuing ioremap() on RAM
From: Uwe Kleine-König @ 2010-10-07 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286454549-19690-1-git-send-email-felipe.contreras@gmail.com>
Hello,
On Thu, Oct 07, 2010 at 03:29:09PM +0300, Felipe Contreras wrote:
> Many drivers are broken, and there's no alternative in sight. Such a big
> change should stay as a warning for now, and only later should it
> actually fail.
>
> The drivers are not doing something correct, we get it, but for now it's
> better to allow them to work (they do 99% of the time anyway) rather
> than to force everyone to revert this patch in their internal trees
> until there's a solution. A slightly broken functionality is better than
> no functionality at all.
>
> A warning lets people know that what they are doing is not right, and
> they should fix it.
>
> Cc: Han Jonghun <jonghun79.han@gmail.com>
> Cc: Hemant Pedanekar <hemantp@ti.com>
> Cc: Arnd Hannemann <arnd@arndnet.de>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> arch/arm/mm/ioremap.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> For issues related to this:
> http://article.gmane.org/gmane.linux.ports.arm.kernel/84454
> http://article.gmane.org/gmane.linux.ports.sh.devel/8560
> http://www.spinics.net/lists/linux-fbdev/msg01745.html
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/22271
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..a168673 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -202,10 +202,9 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> return NULL;
>
> /*
> - * Don't allow RAM to be mapped - this causes problems with ARMv6+
> + * This causes problems with ARMv6+. Will be disallowed soon.
maybe specify soon as "before 2.6.37"?
Other than that, Acked-by: Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de>
because there is no other solution to make it into the kernel before
.36.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: use netif_receive_skb in ieee80211_tx_status callpath
From: Johannes Berg @ 2010-10-07 18:00 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20101007152708.GA20950@tuxdriver.com>
On Thu, 2010-10-07 at 11:27 -0400, John W. Linville wrote:
> > > Alternatively, we can require drivers to call ieee80211_tx_status() with
> > > BHs disabled, but somebody would have to go through them...
> >
> > For RX, we do this with ieee80211_rx_ni().
>
> Right. I thought I had checked all these contexts, but ath9k in
> particular is a bit complicated to trace all the potential callpaths
> by hand.
>
> I'll revert it, and the rtl8180 patch to use napi (which also does
> tx status in that context).
Or you could just add _ni and use it in ath9k all the time -- disabling
already disabled BHs will nest -- and leave it to somebody else to sort
out there later :)
johannes
^ permalink raw reply
* Re: [PATCH v6 06/12] Add PV MSR to enable asynchronous page faults delivery.
From: Gleb Natapov @ 2010-10-07 17:59 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC3F2.2050506@redhat.com>
On Thu, Oct 07, 2010 at 02:58:26PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >+
> >+ Physical address points to 32 bit memory location that will be written
> >+ to by the hypervisor at the time of asynchronous page fault injection to
> >+ indicate type of asynchronous page fault. Value of 1 means that the page
> >+ referred to by the page fault is not present. Value 2 means that the
> >+ page is now available.
>
> "The must not enable interrupts before the reason is read, or it may
> be overwritten by another apf".
>
> Document the fact that disabling interrupts disables APFs.
>
> How does the guest distinguish betweem APFs and ordinary page faults?
>
> What's the role of cr2?
>
> When disabling APF, all pending APFs are flushed and may or may not
> get a completion.
>
> Is a "page available" notification guaranteed to arrive on the same
> vcpu that took the "page not present" fault?
>
You mean documentation is lacking? :)
--
Gleb.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: RFC: btusb firmware load help
From: Johannes Berg @ 2010-10-07 17:59 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, linux-bluetooth,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Deepak Dhamdhere, Sree Durbha
In-Reply-To: <1286465072.6145.151.camel@aeonflux>
On Thu, 2010-10-07 at 17:24 +0200, Marcel Holtmann wrote:
> I am still trying to figure out if this is one stage firmware loading or
> a two stage firmware loading. This is all pretty unclear and nobody has
> answered this clearly so far.
afaict, it's just one stage -- either it has sflash and you load ath3k
firmware over it (the problematic 3002-before-loading case), or it
doesn't have any firmware (and comes up with 3000) and you load the same
ath3k firmware over it with a different mechanism, which currently
announces itself as 3002 but can be changed.
johannes
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Sameer Nanda @ 2010-10-07 17:58 UTC (permalink / raw)
To: Greg KH; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <20101007021959.GA7300@suse.de>
(resending as plain text, sorry if you got dupe messages)
On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Oct 06, 2010 at 04:15:19PM -0700, Sameer Nanda wrote:
>> Read the TSC upon resuming and print it out. This is useful
>> in helping figure out amount of time spent in the BIOS when
>> resuming from suspend.
>>
>> Change-Id: I1d6a32bd62421becddecd152d561763e5f3e1101
>
> What is this tag for? I don't think it matches anything the kernel
> community wants, do you?
Yeah, its not needed. Let me resubmit the patch without this tag.
>
> And are you always going to be printing this out? Why do we want to
> know this every time?
Yes, every time. This helps track variance in BIOS resume times
within a single boot.
>
>> Signed-off-by: Sameer Nanda <snanda@chromium.org>
>> ---
>> drivers/acpi/sleep.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index c0fed2e..f0588fa 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -214,6 +214,7 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
>> acpi_status status = AE_OK;
>> unsigned long flags = 0;
>> u32 acpi_state = acpi_target_sleep_state;
>> + u64 tsc;
>>
>> ACPI_FLUSH_CPU_CACHE();
>>
>> @@ -235,6 +236,9 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
>>
>> case ACPI_STATE_S3:
>> do_suspend_lowlevel();
>> + rdtscll(tsc);
>> + printk(KERN_INFO "TSC at resume: %llu\n",
>> + (unsigned long long)tsc);
>
> How long does this take, will it slow down resume?
The impact is ~10us (as measured on an Intel Atom N455 @ 1.66Ghz).
Given that resume time is currently of the order of 1sec, its in the
noise range.
Thanks for the feedback!
>
> thanks,
>
> greg k-h
>
--
Sameer
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 07/11] cris: avoid write only variables
From: Blue Swirl @ 2010-10-07 17:57 UTC (permalink / raw)
To: Edgar E. Iglesias; +Cc: Markus Armbruster, qemu-devel
In-Reply-To: <20101007110713.GE16104@laped.lan>
On Thu, Oct 7, 2010 at 11:07 AM, Edgar E. Iglesias
<edgar.iglesias@gmail.com> wrote:
> On Thu, Oct 07, 2010 at 12:08:05PM +0200, Markus Armbruster wrote:
>> Blue Swirl <blauwirbel@gmail.com> writes:
>>
>> > Compiling with GCC 4.6.0 20100925 produced warnings:
>> > /src/qemu/target-cris/op_helper.c: In function 'helper_movl_sreg_reg':
>> > /src/qemu/target-cris/op_helper.c:145:8: error: variable 'tlb_v' set
>> > but not used [-Werror=unused-but-set-variable]
>> > In file included from /src/qemu/target-cris/translate.c:3154:0:
>> > /src/qemu/target-cris/translate_v10.c: In function 'dec10_prep_move_m':
>> > /src/qemu/target-cris/translate_v10.c:111:22: error: variable 'rd' set
>> > but not used [-Werror=unused-but-set-variable]
>> >
>> > Fix by making the variable declarations and their uses also conditional
>> > to debug definition, delete rd.
>> >
>> > Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>> > ---
>> > target-cris/op_helper.c | 6 ++++++
>> > target-cris/translate_v10.c | 5 ++---
>> > 2 files changed, 8 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/target-cris/op_helper.c b/target-cris/op_helper.c
>> > index a60da94..28c79b1 100644
>> > --- a/target-cris/op_helper.c
>> > +++ b/target-cris/op_helper.c
>> > @@ -142,7 +142,9 @@ void helper_movl_sreg_reg (uint32_t sreg, uint32_t reg)
>> > uint32_t idx;
>> > uint32_t lo, hi;
>> > uint32_t vaddr;
>> > +#ifdef CRIS_OP_HELPER_DEBUG
>> > int tlb_v;
>> > +#endif
>> >
>> > idx = set = env->sregs[SFR_RW_MM_TLB_SEL];
>> > set >>= 4;
>> > @@ -157,13 +159,17 @@ void helper_movl_sreg_reg (uint32_t sreg, uint32_t reg)
>> > vaddr = EXTRACT_FIELD(env->tlbsets[srs-1][set][idx].hi,
>> > 13, 31);
>> > vaddr <<= TARGET_PAGE_BITS;
>> > +#ifdef CRIS_OP_HELPER_DEBUG
>> > tlb_v = EXTRACT_FIELD(env->tlbsets[srs-1][set][idx].lo,
>> > 3, 3);
>> > +#endif
>> > env->tlbsets[srs - 1][set][idx].lo = lo;
>> > env->tlbsets[srs - 1][set][idx].hi = hi;
>> >
>> > +#ifdef CRIS_OP_HELPER_DEBUG
>> > D_LOG("tlb flush vaddr=%x v=%d pc=%x\n",
>> > vaddr, tlb_v, env->pc);
>> > +#endif
>> > tlb_flush_page(env, vaddr);
>> > }
>> > }
>>
>> Could we eliminate the bothersome variable instead?
>>
>> diff --git a/target-cris/op_helper.c b/target-cris/op_helper.c
>> index a60da94..94e3e27 100644
>> --- a/target-cris/op_helper.c
>> +++ b/target-cris/op_helper.c
>> @@ -142,7 +142,6 @@ void helper_movl_sreg_reg (uint32_t sreg, uint32_t reg)
>> uint32_t idx;
>> uint32_t lo, hi;
>> uint32_t vaddr;
>> - int tlb_v;
>>
>> idx = set = env->sregs[SFR_RW_MM_TLB_SEL];
>> set >>= 4;
>> @@ -157,13 +156,14 @@ void helper_movl_sreg_reg (uint32_t sreg, uint32_t reg)
>> vaddr = EXTRACT_FIELD(env->tlbsets[srs-1][set][idx].hi,
>> 13, 31);
>> vaddr <<= TARGET_PAGE_BITS;
>> - tlb_v = EXTRACT_FIELD(env->tlbsets[srs-1][set][idx].lo,
>> + D_LOG("tlb flush vaddr=%x v=%d pc=%x\n",
>> + vaddr,
>> + EXTRACT_FIELD(env->tlbsets[srs-1][set][idx].lo,
>> 3, 3);
>> + env->pc);
>> env->tlbsets[srs - 1][set][idx].lo = lo;
>> env->tlbsets[srs - 1][set][idx].hi = hi;
>>
>> - D_LOG("tlb flush vaddr=%x v=%d pc=%x\n",
>> - vaddr, tlb_v, env->pc);
>> tlb_flush_page(env, vaddr);
>> }
>> }
>
> Hi,
>
> Sorry for the late answer.
Late? I think my timescale is slightly different than yours :-)
> Markus, I agree that removing tlb_v would have been better than ifdefs,
> but i think that the intent I originally had in mind was that there should
> not be a need to flush the entry from the QEMU TLB if the old guest
> entry was not valid.
>
>
> The following patch works on my side:
>
> diff --git a/target-cris/op_helper.c b/target-cris/op_helper.c
> index a60da94..be9eb06 100644
> --- a/target-cris/op_helper.c
> +++ b/target-cris/op_helper.c
> @@ -164,7 +164,9 @@ void helper_movl_sreg_reg (uint32_t sreg, uint32_t reg)
>
> D_LOG("tlb flush vaddr=%x v=%d pc=%x\n",
> vaddr, tlb_v, env->pc);
> - tlb_flush_page(env, vaddr);
> + if (tlb_v) {
> + tlb_flush_page(env, vaddr);
> + }
> }
> }
> #endif
>
>
> The target-cris/translate_v10.c hunk looks good.
>
> Blue, can you incorporate the tlb_v change in your patch set?
> Or if you prefer, I can commit that part on my side.
Please do.
^ permalink raw reply
* Re: RFC: btusb firmware load help
From: Johannes Berg @ 2010-10-07 17:57 UTC (permalink / raw)
To: Bala Shanmugam
Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, Marcel Holtmann,
linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Deepak Dhamdhere, Sree Durbha
In-Reply-To: <4CADF634.1030203@atheros.com>
On Thu, 2010-10-07 at 22:02 +0530, Bala Shanmugam wrote:
> AR3011 when plugged-in uses PID 3000 and control goes to DFU driver [ath3k].
> ath3k downloads the firmware to the device changing its PID to 3002.
> Now btusb gets the control and attaches the device to bluetooth core.
>
> So blacklisting 3002 in btusb will create issues for AR3011 chipsets.
> In firmware if we change the PID from 3002 to 3003 as you suggested and
> blacklist 3002 in btusb we can make both devices work.
Yeah, that still seems like the best approach, or maybe 3004 instead of
3003 if 3003 is already in use by a different chip, or whatever.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Gustavo F. Padovan @ 2010-10-07 17:57 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Greg KH, pavan-savoy, linux-bluetooth, johan.hedberg,
linux-kernel, Pavan Savoy
In-Reply-To: <1286464867.6145.148.camel@aeonflux>
* Marcel Holtmann <marcel@holtmann.org> [2010-10-07 17:21:07 +0200]:
> Hi Greg,
>
> > > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > > like BT, FM, GPS and WLAN onto a single chip.
> > > >
> > > > This Bluetooth driver works on top of the TI_ST shared transport
> > > > line discipline driver which also allows other drivers like
> > > > FM V4L2 and GPS character driver to make use of the same UART interface.
> > > >
> > > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > > ---
> > > > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> > > > drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> > > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> > >
> > > I don't care about staging at all. So you sort that out with Greg.
> > >
> > > Submit your driver for upstream inclusion. And once accepted you can pin
> > > Greg about removing it.
> >
> > The driver is already in staging, this is the request to move it out of
> > staging and into the "correct" place in the tree. The core of the ti-st
> > code is now in the drivers/misc/ directory in the linux-next tree, and
> > this patch is the request to move the bluetooth drive into the proper
> > drivers/bluetooth/ location.
>
> nice idea, but I don't want it that way. I am not dealing with staging
> at all. They can submit this driver for upstream inclusion and then
> delete it in a second step from staging. Or the other way around.
We just have to be sure to do both steps in the same release cycle,
otherwise we could ship the driver twice in the kernel (considering we
will delete it after merge in drivers/bluetooth/)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* [U-Boot] packed attribute problem
From: Wolfgang Denk @ 2010-10-07 17:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007114634.70e0f197@udp111988uds.am.freescale.net>
Dear Scott Wood,
In message <20101007114634.70e0f197@udp111988uds.am.freescale.net> you wrote:
>
> I think this gets down to how such pointers are generated -- if you
> stick with well-defined C, the compiler/ABI should be able to avoid
> generating an unaligned pointer.
It is a pretty common method to use a pointer to some struct (for
example, some form of PDU) and make it point to some I/O buffer.
Depending on I/O subsystem, pre-pended protocol headerss and such the
resulting pointer may or may not be aligned. This is something that
the compiler has zero influence on. [Yes, of course the application
could always copy the data to a properly aligned memory region. But I
bet you would quickly complain about the poor throughput if the
network stack on your systems were implemented that way.]
> > I may be wrong here, but I cannot
> > think of any statement in the standards in this regard - it's only data
> > types that imply alignments.
>
> Pointers point to typed data...
Yes, and these typed date can be anywhere, even on addresses that
don't match the natural alignment of these data.
> C doesn't guarantee this, and it would be broken on certain chips
Actually I consider this a deficiency in the C specification. I've
been using C since Unix Version 6, and to me it is still mostly a
high-level assembler language. I definitly do not want the compiler
to do different things than what I tell him.
> when unaligned, e.g. old ARM chips that do weird rotaty things rather
> than trap when you do an unaligned access.
I think it was acceptable for such systems to enforce the compiler (by
setting special compiler switches) to implement such extra access modes.
But doing it by default and unconditionally for all systems of that
architecture seems broken to me. It's unfair collective punishment.
But alas. That's how it is in ARM land...
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509 at cs.colorado.edu
^ 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.