* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Avi Kivity @ 2011-10-24 9:45 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, kvm, Michael S. Tsirkin
In-Reply-To: <4EA13917.7070401@siemens.com>
On 10/21/2011 11:19 AM, Jan Kiszka wrote:
> Currently, MSI messages can only be injected to in-kernel irqchips by
> defining a corresponding IRQ route for each message. This is not only
> unhandy if the MSI messages are generated "on the fly" by user space,
> IRQ routes are a limited resource that user space as to manage
> carefully.
By itself, this does not provide enough value to offset the cost of a
new ABI, especially as userspace will need to continue supporting the
old method for a very long while.
> By providing a direct injection with, we can both avoid using up limited
> resources and simplify the necessary steps for user land. The API
> already provides a channel (flags) to revoke an injected but not yet
> delivered message which will become important for in-kernel MSI-X vector
> masking support.
>
With the new feature it may be worthwhile, but I'd like to see the whole
thing, with numbers attached.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: Subvolume level allocation policy
From: Jan Schmidt @ 2011-10-24 9:44 UTC (permalink / raw)
To: Phillip Susi; +Cc: linux-btrfs
In-Reply-To: <4EA4620A.3060702@cfl.rr.com>
On 23.10.2011 20:50, Phillip Susi wrote:
> Is it ( yet? ) possible to manipulate the allocation policy on a
> subvolume level instead of the fs level? For example, to make / use
> raid1, and /home use raid0? Or to have / allocated from an ssd and
> /home allocated from the giant 2tb hd.
At least the latter can be achieved with speed profiles. I worked on
those together with Arne Jansen who sent patches in January 2011,
subject "[PATCH] Btrfs: introducing speed profiles and dedicated log
devices".
I don't assume they apply nowadays without a major rework, though. We
should get those patches merged sometime.
-Jan
^ permalink raw reply
* Ofono use
From: Jean Parpaillon @ 2011-10-24 9:44 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
Hi all,
I am currently trying to use ofono and I can not get how to register the
modem in a reliable way.
When I detect a modem, I set org.ofono.Modem.Powered to True.
When SimManager interface is ready, I enter the pin.
Then, I set the modem org.ofono.Modem.Online to True.
By the way, I wait for NetworkRegistration interface to be available.
When it is available, I wait for NetworkRegistration.Name to be non
empty to call NetworkRegistration.Register.
The point is setting Online property usually end with a timeout. It is
the right workflow ? Must I look for other property ?
In a few words, what is the right workflow to get a UMTS modem
registered to its default network from the moment you plug it in ?
Any piece of a clue will be appreciated :)
Regards,
Jean
^ permalink raw reply
* [PATCH 6/6] staging:iio: trigger fixes for repeat request of same trigger and allocation failure
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
Both of these are decidedly silly bugs show up whilst testing
completely different code paths.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/industrialio-trigger.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/iio/industrialio-trigger.c b/drivers/staging/iio/industrialio-trigger.c
index 9412013..20dc8e8 100644
--- a/drivers/staging/iio/industrialio-trigger.c
+++ b/drivers/staging/iio/industrialio-trigger.c
@@ -220,8 +220,16 @@ static int iio_trigger_attach_poll_func(struct iio_trigger *trig,
ret = request_threaded_irq(pf->irq, pf->h, pf->thread,
pf->type, pf->name,
pf);
- if (trig->ops && trig->ops->set_trigger_state && notinuse)
+ if (ret < 0) {
+ module_put(pf->indio_dev->info->driver_module);
+ return ret;
+ }
+
+ if (trig->ops && trig->ops->set_trigger_state && notinuse) {
ret = trig->ops->set_trigger_state(trig, true);
+ if (ret < 0)
+ module_put(pf->indio_dev->info->driver_module);
+ }
return ret;
}
@@ -334,6 +342,8 @@ static ssize_t iio_trigger_write_current(struct device *dev,
mutex_unlock(&indio_dev->mlock);
trig = iio_trigger_find_by_name(buf, len);
+ if (oldtrig == trig)
+ return len;
if (trig && indio_dev->info->validate_trigger) {
ret = indio_dev->info->validate_trigger(indio_dev, trig);
--
1.7.7
^ permalink raw reply related
* [PATCH 3/6] staging:iio:triggers Remove unecessary existence checks and return val
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
Postenable and predisable are called via buffer->ops so don't
need to check if buffer exists.
The return value of iio_device_register_trigger_consumer is
always zero and it isn't checked anyway so get rid of it.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/iio_core_trigger.h | 3 +--
drivers/staging/iio/industrialio-trigger.c | 16 +++++-----------
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/iio/iio_core_trigger.h b/drivers/staging/iio/iio_core_trigger.h
index 523c288..6f7c56f 100644
--- a/drivers/staging/iio/iio_core_trigger.h
+++ b/drivers/staging/iio/iio_core_trigger.h
@@ -13,8 +13,7 @@
* iio_device_register_trigger_consumer() - set up an iio_dev to use triggers
* @indio_dev: iio_dev associated with the device that will consume the trigger
**/
-
-int iio_device_register_trigger_consumer(struct iio_dev *indio_dev);
+void iio_device_register_trigger_consumer(struct iio_dev *indio_dev);
/**
* iio_device_unregister_trigger_consumer() - reverse the registration process
diff --git a/drivers/staging/iio/industrialio-trigger.c b/drivers/staging/iio/industrialio-trigger.c
index 2c626e0..ca4124a 100644
--- a/drivers/staging/iio/industrialio-trigger.c
+++ b/drivers/staging/iio/industrialio-trigger.c
@@ -473,12 +473,10 @@ void iio_free_trigger(struct iio_trigger *trig)
}
EXPORT_SYMBOL(iio_free_trigger);
-int iio_device_register_trigger_consumer(struct iio_dev *indio_dev)
+void iio_device_register_trigger_consumer(struct iio_dev *indio_dev)
{
indio_dev->groups[indio_dev->groupcounter++] =
&iio_trigger_consumer_attr_group;
-
- return 0;
}
void iio_device_unregister_trigger_consumer(struct iio_dev *indio_dev)
@@ -490,18 +488,14 @@ void iio_device_unregister_trigger_consumer(struct iio_dev *indio_dev)
int iio_triggered_buffer_postenable(struct iio_dev *indio_dev)
{
- return indio_dev->trig
- ? iio_trigger_attach_poll_func(indio_dev->trig,
- indio_dev->pollfunc)
- : 0;
+ return iio_trigger_attach_poll_func(indio_dev->trig,
+ indio_dev->pollfunc);
}
EXPORT_SYMBOL(iio_triggered_buffer_postenable);
int iio_triggered_buffer_predisable(struct iio_dev *indio_dev)
{
- return indio_dev->trig
- ? iio_trigger_dettach_poll_func(indio_dev->trig,
- indio_dev->pollfunc)
- : 0;
+ return iio_trigger_dettach_poll_func(indio_dev->trig,
+ indio_dev->pollfunc);
}
EXPORT_SYMBOL(iio_triggered_buffer_predisable);
--
1.7.7
^ permalink raw reply related
* [PATCH 2/6] staging:iio:light:tsl2563 missing setting of id in get id function.
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Maxin B. John, Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
From: "Maxin B. John" <maxin.john@gmail.com>
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/light/tsl2563.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c
index be99925..6a17945 100644
--- a/drivers/staging/iio/light/tsl2563.c
+++ b/drivers/staging/iio/light/tsl2563.c
@@ -226,6 +226,8 @@ static int tsl2563_read_id(struct tsl2563_chip *chip, u8 *id)
if (ret < 0)
return ret;
+ *id = ret;
+
return 0;
}
--
1.7.7
^ permalink raw reply related
* [PATCH 1/6] staging:iio:light:tsl2563 both intensity channels have same chan_spec.
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
Bug has been fixed for some time in the outofstaging tree, but
didn't propogate back to here.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/light/tsl2563.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c
index 7e984bc..be99925 100644
--- a/drivers/staging/iio/light/tsl2563.c
+++ b/drivers/staging/iio/light/tsl2563.c
@@ -544,7 +544,7 @@ static const struct iio_chan_spec tsl2563_channels[] = {
}, {
.type = IIO_INTENSITY,
.modified = 1,
- .channel2 = IIO_MOD_LIGHT_BOTH,
+ .channel2 = IIO_MOD_LIGHT_IR,
.info_mask = (1 << IIO_CHAN_INFO_CALIBSCALE_SEPARATE),
}
};
--
1.7.7
^ permalink raw reply related
* [PATCH 4/6] staging:iio:industrialio-trigger.c Trivial code style brackets fix
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/industrialio-trigger.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/industrialio-trigger.c b/drivers/staging/iio/industrialio-trigger.c
index ca4124a..9412013 100644
--- a/drivers/staging/iio/industrialio-trigger.c
+++ b/drivers/staging/iio/industrialio-trigger.c
@@ -159,13 +159,12 @@ EXPORT_SYMBOL(iio_trigger_generic_data_rdy_poll);
void iio_trigger_poll_chained(struct iio_trigger *trig, s64 time)
{
int i;
- if (!trig->use_count) {
+ if (!trig->use_count)
for (i = 0; i < CONFIG_IIO_CONSUMERS_PER_TRIGGER; i++)
if (trig->subirqs[i].enabled) {
trig->use_count++;
handle_nested_irq(trig->subirq_base + i);
}
- }
}
EXPORT_SYMBOL(iio_trigger_poll_chained);
@@ -173,10 +172,9 @@ void iio_trigger_notify_done(struct iio_trigger *trig)
{
trig->use_count--;
if (trig->use_count == 0 && trig->ops && trig->ops->try_reenable)
- if (trig->ops->try_reenable(trig)) {
+ if (trig->ops->try_reenable(trig))
/* Missed and interrupt so launch new poll now */
iio_trigger_poll(trig, 0);
- }
}
EXPORT_SYMBOL(iio_trigger_notify_done);
--
1.7.7
^ permalink raw reply related
* [PATCH 5/6] staging:iio:kfifo remove entirely pointless code.
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
In-Reply-To: <1319449415-23269-1-git-send-email-jic23@cam.ac.uk>
I really don't want to think about how this bit got
in there. It allocates some storage - copies something
into it then frees it without making use of it.
Oops.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
---
drivers/staging/iio/kfifo_buf.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/iio/kfifo_buf.c b/drivers/staging/iio/kfifo_buf.c
index e8c234b..fd98a0e 100644
--- a/drivers/staging/iio/kfifo_buf.c
+++ b/drivers/staging/iio/kfifo_buf.c
@@ -150,16 +150,9 @@ static int iio_store_to_kfifo(struct iio_buffer *r,
{
int ret;
struct iio_kfifo *kf = iio_to_kfifo(r);
- u8 *datal = kmalloc(r->bytes_per_datum, GFP_KERNEL);
- memcpy(datal, data, r->bytes_per_datum - sizeof(timestamp));
- memcpy(datal + r->bytes_per_datum - sizeof(timestamp),
- ×tamp, sizeof(timestamp));
ret = kfifo_in(&kf->kf, data, r->bytes_per_datum);
- if (ret != r->bytes_per_datum) {
- kfree(datal);
+ if (ret != r->bytes_per_datum)
return -EBUSY;
- }
- kfree(datal);
return 0;
}
--
1.7.7
^ permalink raw reply related
* [PATCH 0/6] staging:iio: misc fixes
From: Jonathan Cameron @ 2011-10-24 9:43 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
Hi All,
I've just gathered up the fixes sitting in my various trees
ready to send on. I have lost track of whether all of these
have previously been posted for review so this is to make
sure they all have. They are all in the github master branch.
I'd like to push these out before the larger changes that
Lars-Peter and I made at the end of last week.
Thanks,
Jonathan
Jonathan Cameron (5):
staging:iio:light:tsl2563 both intensity channels have same
chan_spec.
staging:iio:triggers Remove unecessary existence checks and return
val
staging:iio:industrialio-trigger.c Trivial code style brackets fix
staging:iio:kfifo remove entirely pointless code.
staging:iio: trigger fixes for repeat request of same trigger and
allocation failure
Maxin B. John (1):
staging:iio:light:tsl2563 missing setting of id in get id function.
drivers/staging/iio/iio_core_trigger.h | 3 +-
drivers/staging/iio/industrialio-trigger.c | 34 ++++++++++++++-------------
drivers/staging/iio/kfifo_buf.c | 9 +------
drivers/staging/iio/light/tsl2563.c | 4 ++-
4 files changed, 23 insertions(+), 27 deletions(-)
--
1.7.7
^ permalink raw reply
* Re: [PATCH RFC V2 2/5] debugfs: Renaming of xen functions and change unsigned to u32
From: Greg KH @ 2011-10-24 9:38 UTC (permalink / raw)
To: Raghavendra K T
Cc: Raghavendra K T, KVM, Konrad Rzeszutek Wilk, Sedat Dilek,
Virtualization, Jeremy Fitzhardinge, x86, H. Peter Anvin,
Dave Jiang, Thomas Gleixner, Stefano Stabellini, Gleb Natapov,
Yinghai Lu, Marcelo Tosatti, Ingo Molnar, Avi Kivity,
Rik van Riel, Xen, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra
In-Reply-To: <4EA52FCF.2090508@linux.vnet.ibm.com>
On Mon, Oct 24, 2011 at 02:58:47PM +0530, Raghavendra K T wrote:
> On 10/24/2011 03:49 AM, Greg KH wrote:
> >On Mon, Oct 24, 2011 at 12:34:59AM +0530, Raghavendra K T wrote:
> >>Renaming of xen functions and change unsigned to u32.
> >
> >Why not just rename when you move the functions? Why the extra step?
> >
> Intention was only clarity. Yes, if this patch is an overhead, I 'll
> combine both the patches.
Yeah, it makes more sense as it originally confused me why you were
adding a "xen_*" function to the debugfs core code :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 9:42 UTC (permalink / raw)
To: Ulf Hansson
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lee Jones
In-Reply-To: <4EA53181.2050700@stericsson.com>
On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
> Russell King - ARM Linux wrote:
>> I repeat: if you cut power to the card, you have to re-initialize it.
>> Re-initialization takes quite a bit of time to re-detect and setup
>> the card. You'd also need to re-configure things like the transfer
>> mode and so forth.
>
> Right now host->vcc (vmmc) regulator is controlling the power to card.
> Not the MCIPWR register!
Maybe for you, but that's not the case on all platforms.
You *really* need to get out of the idea that just because your
implementation works one way that everything works that way. You're
working on a cross-SoC cross-platform driver, and you need to take
account of how other platforms work.
In that case, there *are* platforms which the MCIPWR register does
indeed control power to the card - and setting this to zero _will_
power down the card.
> I would be very surprised if any hardware has this kind of setup, that
> the PL180 itself controls a regulator.
ARM dev boards all use the MCIPWR bits to control an external power
switch - there's no adjustment of the voltage except via soldered
links on the board.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA53181.2050700@stericsson.com>
On Mon, Oct 24, 2011 at 11:36:01AM +0200, Ulf Hansson wrote:
> Russell King - ARM Linux wrote:
>> I repeat: if you cut power to the card, you have to re-initialize it.
>> Re-initialization takes quite a bit of time to re-detect and setup
>> the card. You'd also need to re-configure things like the transfer
>> mode and so forth.
>
> Right now host->vcc (vmmc) regulator is controlling the power to card.
> Not the MCIPWR register!
Maybe for you, but that's not the case on all platforms.
You *really* need to get out of the idea that just because your
implementation works one way that everything works that way. You're
working on a cross-SoC cross-platform driver, and you need to take
account of how other platforms work.
In that case, there *are* platforms which the MCIPWR register does
indeed control power to the card - and setting this to zero _will_
power down the card.
> I would be very surprised if any hardware has this kind of setup, that
> the PL180 itself controls a regulator.
ARM dev boards all use the MCIPWR bits to control an external power
switch - there's no adjustment of the voltage except via soldered
links on the board.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 9:40 UTC (permalink / raw)
To: Kevin Wolf; +Cc: avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA53184.8080201@redhat.com>
On 10/24/2011 11:36 AM, Kevin Wolf wrote:
>> > You're changing the API and asking for possibly non-trivial changes in
>> > all protocol drivers, in order to accomodate semantics that all format
>> > drivers potentially could desire. So I wonder if the problem is simply
>> > that the current API is not expressive enough.
> Can you think of any cases where a caller would want to invoke
> bdrv_flush, but not bdrv_fsync? (The other way round it makes even less
> sense)
I'm talking about the internal driver API only. The external API is
fine as is.
Paolo
^ permalink raw reply
* Re: NFS4 client blocked (kernel 3.0.7)
From: Trond Myklebust @ 2011-10-24 9:40 UTC (permalink / raw)
To: dilip.daya; +Cc: linux-nfs@vger.kernel.org, David Flynn
In-Reply-To: <1319299218.2590.10.camel@pro6455b.example.com>
On Sat, 2011-10-22 at 12:00 -0400, Dilip Daya wrote:
> See below...
>
> 0n Sat, 2011-10-22 at 08:28 +0000, David Flynn wrote:
> > Dear all,
> >
> > When mounting a solaris NFS4 export on a v3.0.4 client, we've experienced
> > processes becoming blocked. Any further attempt to access the mountpoint
> > from another process also blocks. Other mountpoints are unaffected.
> > I have not identified a test case to reproduce the behaviour.
> >
> > Any thoughts on the matter would be most welcome,
> >
> > Kind regards,
> >
> > ..david
> >
> > from /proc/mounts:
> > home:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.29.190.20,minorversion=0,local_lock=none,addr=172.29.120.140 0 0
> >
> > [105121.204200] INFO: task bash:4457 blocked for more than 120 seconds.
> > [105121.247424] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [105121.299955] bash D ffffffff818050a0 0 4457 1 0x00000000
> > [105121.347840] ffff8802954b5c28 0000000000000082 ffff8802954b5db8 0000000000012a40
> > [105121.397793] ffff8802954b5fd8 0000000000012a40 ffff8802954b4000 0000000000012a40
> > [105121.441724] 0000000000012a40 0000000000012a40 ffff8802954b5fd8 0000000000012a40
> > [105121.441728] Call Trace:
> > [105121.441740] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> > [105121.441744] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> > [105121.441746] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> > [105121.441749] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> > [105121.441751] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> > [105121.441756] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> > [105121.441759] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> > [105121.441761] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> > [105121.441786] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> > [105121.441789] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> > [105121.441791] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> > [105121.441793] [<ffffffff8111050b>] filemap_fdatawait+0x2b/0x30
> > [105121.441795] [<ffffffff81112124>] filemap_write_and_wait+0x44/0x60
> > [105121.441803] [<ffffffffa0232805>] nfs_getattr+0x105/0x120 [nfs]
> > [105121.441806] [<ffffffff81605e88>] ? do_page_fault+0x258/0x550
> > [105121.441810] [<ffffffff81175b31>] vfs_getattr+0x51/0x120
> > [105121.441812] [<ffffffff81175c70>] vfs_fstatat+0x70/0x90
> > [105121.441814] [<ffffffff81175ccb>] vfs_stat+0x1b/0x20
> > [105121.441816] [<ffffffff81175f14>] sys_newstat+0x24/0x40
> > [105121.441820] [<ffffffff8101449a>] ? init_fpu+0x4a/0x150
> > [105121.441822] [<ffffffff81602955>] ? page_fault+0x25/0x30
> > [105121.441825] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
> > [105121.441837] INFO: task bash:5612 blocked for more than 120 seconds.
> > [105121.441838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [105121.441840] bash D 0000000000000005 0 5612 1 0x00000000
> > [105121.441843] ffff8801f25d5ca8 0000000000000086 ffff8800163e9b08 0000000000012a40
> > [105121.441845] ffff8801f25d5fd8 0000000000012a40 ffff8801f25d4000 0000000000012a40
> > [105121.441848] 0000000000012a40 0000000000012a40 ffff8801f25d5fd8 0000000000012a40
> > [105121.441850] Call Trace:
> > [105121.441853] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> > [105121.441855] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> > [105121.441857] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> > [105121.441859] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> > [105121.441861] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> > [105121.441863] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> > [105121.441866] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> > [105121.441868] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> > [105121.441876] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> > [105121.441878] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> > [105121.441880] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> > [105121.441882] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
> > [105121.441886] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
> > [105121.441888] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
> > [105121.441894] [<ffffffffa022ec74>] nfs_file_flush+0x54/0x80 [nfs]
> > [105121.441898] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
> > [105121.441900] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
> > [105121.441902] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
> > --
>
> Same issue!
>
> In my case I have NFS client & server both with Linux kernel
> v3.0.7-stable.
>
>
> Kernel: v3.0.7-stable (amd64)
>
> # nfsstat -m
> /opt/xorsyst/nfs_test from 192.168.1.53:/opt/xorsyst/nfs_test
> Flags:
> rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=192.168.1.52,minorversion=0,local_lock=none,addr=192.168.1.53
Sigh... Why are you using udp with timeo!=default? You do realise that
unlike tcp, udp is a lossy protocol with no guarantee that messages will
actually be delivered to the server?
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* [Qemu-devel] [PATCH] hw/9pfs: Make VirtFS tracing work correctly
From: Aneesh Kumar K.V @ 2011-10-24 9:39 UTC (permalink / raw)
To: qemu-devel; +Cc: aliguori, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
this patch fix multiple issues with VirtFS tracing.
a) Add tracepoint to the correct code path. We handle error in complete_pdu
b) Fix indentation in python script
c) Fix variable naming issue in python script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
hw/9pfs/virtio-9p.c | 60 +++++++-------
scripts/analyse-9p-simpletrace.py | 164 ++++++++++++++++++------------------
trace-events | 2 +-
3 files changed, 112 insertions(+), 114 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index aab3beb..8b6813f 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -969,7 +969,7 @@ static void complete_pdu(V9fsState *s, V9fsPDU *pdu, ssize_t len)
if (s->proto_version == V9FS_PROTO_2000L) {
id = P9_RLERROR;
}
- trace_complete_pdu(pdu->tag, pdu->id, err); /* Trace ERROR */
+ trace_v9fs_rerror(pdu->tag, pdu->id, err); /* Trace ERROR */
}
/* fill out the header */
@@ -1332,11 +1332,11 @@ static void v9fs_attach(void *opaque)
}
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_attach_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_attach_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&uname);
v9fs_string_free(&aname);
@@ -1371,13 +1371,12 @@ static void v9fs_stat(void *opaque)
}
offset += pdu_marshal(pdu, offset, "wS", 0, &v9stat);
err = offset;
+ trace_v9fs_stat_return(pdu->tag, pdu->id, v9stat.mode,
+ v9stat.atime, v9stat.mtime, v9stat.length);
v9fs_stat_free(&v9stat);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_stat_return(pdu->tag, pdu->id, v9stat.mode,
- v9stat.atime, v9stat.mtime, v9stat.length);
-
complete_pdu(s, pdu, err);
}
@@ -1421,13 +1420,12 @@ static void v9fs_getattr(void *opaque)
}
retval = offset;
retval += pdu_marshal(pdu, offset, "A", &v9stat_dotl);
-out:
- put_fid(pdu, fidp);
-out_nofid:
trace_v9fs_getattr_return(pdu->tag, pdu->id, v9stat_dotl.st_result_mask,
v9stat_dotl.st_mode, v9stat_dotl.st_uid,
v9stat_dotl.st_gid);
-
+out:
+ put_fid(pdu, fidp);
+out_nofid:
complete_pdu(s, pdu, retval);
}
@@ -1605,6 +1603,7 @@ static void v9fs_walk(void *opaque)
v9fs_path_copy(&newfidp->path, &path);
}
err = v9fs_walk_marshal(pdu, nwnames, qids);
+ trace_v9fs_walk_return(pdu->tag, pdu->id, nwnames, qids);
out:
put_fid(pdu, fidp);
if (newfidp) {
@@ -1613,7 +1612,6 @@ out:
v9fs_path_free(&dpath);
v9fs_path_free(&path);
out_nofid:
- trace_v9fs_walk_return(pdu->tag, pdu->id, nwnames, qids);
complete_pdu(s, pdu, err);
if (nwnames && nwnames <= P9_MAXWELEM) {
for (name_idx = 0; name_idx < nwnames; name_idx++) {
@@ -1648,10 +1646,10 @@ static int32_t get_iounit(V9fsPDU *pdu, V9fsPath *path)
static void v9fs_open(void *opaque)
{
int flags;
- int iounit;
int32_t fid;
int32_t mode;
V9fsQID qid;
+ int iounit = 0;
ssize_t err = 0;
size_t offset = 7;
struct stat stbuf;
@@ -1709,11 +1707,11 @@ static void v9fs_open(void *opaque)
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
}
+ trace_v9fs_open_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_open_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(s, pdu, err);
}
@@ -1759,11 +1757,11 @@ static void v9fs_lcreate(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
+ trace_v9fs_lcreate_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_lcreate_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
}
@@ -1978,10 +1976,10 @@ static void v9fs_read(void *opaque)
} else {
err = -EINVAL;
}
+ trace_v9fs_read_return(pdu->tag, pdu->id, count, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_read_return(pdu->tag, pdu->id, count, err);
complete_pdu(s, pdu, err);
}
@@ -2090,10 +2088,10 @@ static void v9fs_readdir(void *opaque)
retval = offset;
retval += pdu_marshal(pdu, offset, "d", count);
retval += count;
+ trace_v9fs_readdir_return(pdu->tag, pdu->id, count, retval);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_readdir_return(pdu->tag, pdu->id, count, retval);
complete_pdu(s, pdu, retval);
}
@@ -2202,10 +2200,10 @@ static void v9fs_write(void *opaque)
} while (total < count && len > 0);
offset += pdu_marshal(pdu, offset, "d", total);
err = offset;
+ trace_v9fs_write_return(pdu->tag, pdu->id, total, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_write_return(pdu->tag, pdu->id, total, err);
complete_pdu(s, pdu, err);
}
@@ -2362,11 +2360,11 @@ static void v9fs_create(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Qd", &qid, iounit);
err = offset;
+ trace_v9fs_create_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, iounit);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_create_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, iounit);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
v9fs_string_free(&extension);
@@ -2401,11 +2399,11 @@ static void v9fs_symlink(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_symlink_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, dfidp);
out_nofid:
- trace_v9fs_symlink_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
v9fs_string_free(&symname);
@@ -2950,10 +2948,11 @@ static void v9fs_mknod(void *opaque)
stat_to_qid(&stbuf, &qid);
err = offset;
err += pdu_marshal(pdu, offset, "Q", &qid);
+ trace_v9fs_mknod_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_mknod_return(pdu->tag, pdu->id, qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&name);
}
@@ -3049,12 +3048,11 @@ static void v9fs_getlock(void *opaque)
glock->start, glock->length, glock->proc_id,
&glock->client_id);
err = offset;
+ trace_v9fs_getlock_return(pdu->tag, pdu->id, glock->type, glock->start,
+ glock->length, glock->proc_id);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_getlock_return(pdu->tag, pdu->id, glock->type, glock->start,
- glock->length, glock->proc_id);
-
complete_pdu(s, pdu, err);
v9fs_string_free(&glock->client_id);
g_free(glock);
@@ -3089,11 +3087,11 @@ static void v9fs_mkdir(void *opaque)
stat_to_qid(&stbuf, &qid);
offset += pdu_marshal(pdu, offset, "Q", &qid);
err = offset;
+ trace_v9fs_mkdir_return(pdu->tag, pdu->id,
+ qid.type, qid.version, qid.path, err);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_mkdir_return(pdu->tag, pdu->id,
- qid.type, qid.version, qid.path, err);
complete_pdu(pdu->s, pdu, err);
v9fs_string_free(&name);
}
@@ -3183,13 +3181,13 @@ static void v9fs_xattrwalk(void *opaque)
offset += pdu_marshal(pdu, offset, "q", size);
err = offset;
}
+ trace_v9fs_xattrwalk_return(pdu->tag, pdu->id, size);
out:
put_fid(pdu, file_fidp);
if (xattr_fidp) {
put_fid(pdu, xattr_fidp);
}
out_nofid:
- trace_v9fs_xattrwalk_return(pdu->tag, pdu->id, size);
complete_pdu(s, pdu, err);
v9fs_string_free(&name);
}
@@ -3260,11 +3258,11 @@ static void v9fs_readlink(void *opaque)
}
offset += pdu_marshal(pdu, offset, "s", &target);
err = offset;
+ trace_v9fs_readlink_return(pdu->tag, pdu->id, target.data);
v9fs_string_free(&target);
out:
put_fid(pdu, fidp);
out_nofid:
- trace_v9fs_readlink_return(pdu->tag, pdu->id, target.data);
complete_pdu(pdu->s, pdu, err);
}
diff --git a/scripts/analyse-9p-simpletrace.py b/scripts/analyse-9p-simpletrace.py
index 4358d6b..b6d58fd 100755
--- a/scripts/analyse-9p-simpletrace.py
+++ b/scripts/analyse-9p-simpletrace.py
@@ -7,11 +7,11 @@
import simpletrace
class VirtFSRequestTracker(simpletrace.Analyzer):
- def begin(self):
- print "Pretty printing 9p simpletrace log ..."
+ def begin(self):
+ print "Pretty printing 9p simpletrace log ..."
- def complete_pdu(self, tag, id, err):
- print "ERROR (tag =", tag, ", id =", id, ",err =", err, ")"
+ def v9fs_rerror(self, tag, id, err):
+ print "RERROR (tag =", tag, ", id =", id, ",err =", err, ")"
def v9fs_version(self, tag, id, msize, version):
print "TVERSION (tag =", tag, ", msize =", msize, ", version =", version, ")"
@@ -22,121 +22,121 @@ class VirtFSRequestTracker(simpletrace.Analyzer):
def v9fs_attach(self, tag, id, fid, afid, uname, aname):
print "TATTACH (tag =", tag, ", fid =", fid, ", afid =", afid, ", uname =", uname, ", aname =", aname, ")"
- def v9fs_attach_return(self, tag, id, type, verison, path):
- print "RATTACH (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
+ def v9fs_attach_return(self, tag, id, type, version, path):
+ print "RATTACH (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
- def v9fs_stat(self, tag, id, fid):
- print "TSTAT (tag =", tag, ", fid =", fid, ")"
+ def v9fs_stat(self, tag, id, fid):
+ print "TSTAT (tag =", tag, ", fid =", fid, ")"
- def v9fs_stat_return(self, tag, id, mode, atime, mtime, length):
- print "RSTAT (tag =", tag, ", mode =", mode, ", atime =", atime, ", mtime =", mtime, ", length =", length, ")"
+ def v9fs_stat_return(self, tag, id, mode, atime, mtime, length):
+ print "RSTAT (tag =", tag, ", mode =", mode, ", atime =", atime, ", mtime =", mtime, ", length =", length, ")"
- def v9fs_getattr(self, tag, id, fid, request_mask):
- print "TGETATTR (tag =", tag, ", fid =", fid, ", request_mask =", hex(request_mask), ")"
+ def v9fs_getattr(self, tag, id, fid, request_mask):
+ print "TGETATTR (tag =", tag, ", fid =", fid, ", request_mask =", hex(request_mask), ")"
- def v9fs_getattr_return(self, tag, id, result_mask, mode, uid, gid):
- print "RGETATTR (tag =", tag, ", result_mask =", hex(result_mask), ", mode =", oct(mode), ", uid =", uid, ", gid =", gid, ")"
+ def v9fs_getattr_return(self, tag, id, result_mask, mode, uid, gid):
+ print "RGETATTR (tag =", tag, ", result_mask =", hex(result_mask), ", mode =", oct(mode), ", uid =", uid, ", gid =", gid, ")"
- def v9fs_walk(self, tag, id, fid, newfid, nwnames):
- print "TWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", nwnames =", nwnames, ")"
+ def v9fs_walk(self, tag, id, fid, newfid, nwnames):
+ print "TWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", nwnames =", nwnames, ")"
- def v9fs_walk_return(self, tag, id, nwnames, qids):
- print "RWALK (tag =", tag, ", nwnames =", nwnames, ", qids =", hex(qids), ")"
+ def v9fs_walk_return(self, tag, id, nwnames, qids):
+ print "RWALK (tag =", tag, ", nwnames =", nwnames, ", qids =", hex(qids), ")"
- def v9fs_open(self, tag, id, fid, mode):
- print "TOPEN (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ")"
+ def v9fs_open(self, tag, id, fid, mode):
+ print "TOPEN (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ")"
- def v9fs_open_return(self, tag, id, type, version, path, iounit):
- print "ROPEN (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_open_return(self, tag, id, type, version, path, iounit):
+ print "ROPEN (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_lcreate(self, tag, id, dfid, flags, mode, gid):
- print "TLCREATE (tag =", tag, ", dfid =", dfid, ", flags =", oct(flags), ", mode =", oct(mode), ", gid =", gid, ")"
+ def v9fs_lcreate(self, tag, id, dfid, flags, mode, gid):
+ print "TLCREATE (tag =", tag, ", dfid =", dfid, ", flags =", oct(flags), ", mode =", oct(mode), ", gid =", gid, ")"
- def v9fs_lcreate_return(self, id, type, version, path, iounit):
- print "RLCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_lcreate_return(self, tag, id, type, version, path, iounit):
+ print "RLCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_fsync(self, tag, id, fid, datasync):
- print "TFSYNC (tag =", tag, ", fid =", fid, ", datasync =", datasync, ")"
+ def v9fs_fsync(self, tag, id, fid, datasync):
+ print "TFSYNC (tag =", tag, ", fid =", fid, ", datasync =", datasync, ")"
- def v9fs_clunk(self, tag, id, fid):
- print "TCLUNK (tag =", tag, ", fid =", fid, ")"
+ def v9fs_clunk(self, tag, id, fid):
+ print "TCLUNK (tag =", tag, ", fid =", fid, ")"
- def v9fs_read(self, tag, id, fid, off, max_count):
- print "TREAD (tag =", tag, ", fid =", fid, ", off =", off, ", max_count =", max_count, ")"
+ def v9fs_read(self, tag, id, fid, off, max_count):
+ print "TREAD (tag =", tag, ", fid =", fid, ", off =", off, ", max_count =", max_count, ")"
- def v9fs_read_return(self, tag, id, count, err):
- print "RREAD (tag =", tag, ", count =", count, ", err =", err, ")"
+ def v9fs_read_return(self, tag, id, count, err):
+ print "RREAD (tag =", tag, ", count =", count, ", err =", err, ")"
- def v9fs_readdir(self, tag, id, fid, offset, max_count):
- print "TREADDIR (tag =", tag, ", fid =", fid, ", offset =", offset, ", max_count =", max_count, ")"
+ def v9fs_readdir(self, tag, id, fid, offset, max_count):
+ print "TREADDIR (tag =", tag, ", fid =", fid, ", offset =", offset, ", max_count =", max_count, ")"
- def v9fs_readdir_return(self, tag, id, count, retval):
- print "RREADDIR (tag =", tag, ", count =", count, ", retval =", retval, ")"
+ def v9fs_readdir_return(self, tag, id, count, retval):
+ print "RREADDIR (tag =", tag, ", count =", count, ", retval =", retval, ")"
- def v9fs_write(self, tag, id, fid, off, count, cnt):
- print "TWRITE (tag =", tag, ", fid =", fid, ", off =", off, ", count =", count, ", cnt =", cnt, ")"
+ def v9fs_write(self, tag, id, fid, off, count, cnt):
+ print "TWRITE (tag =", tag, ", fid =", fid, ", off =", off, ", count =", count, ", cnt =", cnt, ")"
- def v9fs_write_return(self, tag, id, total, err):
- print "RWRITE (tag =", tag, ", total =", total, ", err =", err, ")"
+ def v9fs_write_return(self, tag, id, total, err):
+ print "RWRITE (tag =", tag, ", total =", total, ", err =", err, ")"
- def v9fs_create(self, tag, id, fid, perm, name, mode):
- print "TCREATE (tag =", tag, ", fid =", fid, ", perm =", oct(perm), ", name =", name, ", mode =", oct(mode), ")"
+ def v9fs_create(self, tag, id, fid, name, perm, mode):
+ print "TCREATE (tag =", tag, ", fid =", fid, ", perm =", oct(perm), ", name =", name, ", mode =", oct(mode), ")"
- def v9fs_create_return(self, tag, id, type, verison, path, iounit):
- print "RCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
+ def v9fs_create_return(self, tag, id, type, version, path, iounit):
+ print "RCREATE (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, iounit =", iounit, ")"
- def v9fs_symlink(self, tag, id, fid, name, symname, gid):
- print "TSYMLINK (tag =", tag, ", fid =", fid, ", name =", name, ", symname =", symname, ", gid =", gid, ")"
+ def v9fs_symlink(self, tag, id, fid, name, symname, gid):
+ print "TSYMLINK (tag =", tag, ", fid =", fid, ", name =", name, ", symname =", symname, ", gid =", gid, ")"
- def v9fs_symlink_return(self, tag, id, type, version, path):
- print "RSYMLINK (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
+ def v9fs_symlink_return(self, tag, id, type, version, path):
+ print "RSYMLINK (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "})"
- def v9fs_flush(self, tag, id, flush_tag):
- print "TFLUSH (tag =", tag, ", flush_tag =", flush_tag, ")"
+ def v9fs_flush(self, tag, id, flush_tag):
+ print "TFLUSH (tag =", tag, ", flush_tag =", flush_tag, ")"
- def v9fs_link(self, tag, id, dfid, oldfid, name):
- print "TLINK (tag =", tag, ", dfid =", dfid, ", oldfid =", oldfid, ", name =", name, ")"
+ def v9fs_link(self, tag, id, dfid, oldfid, name):
+ print "TLINK (tag =", tag, ", dfid =", dfid, ", oldfid =", oldfid, ", name =", name, ")"
- def v9fs_remove(self, tag, id, fid):
- print "TREMOVE (tag =", tag, ", fid =", fid, ")"
+ def v9fs_remove(self, tag, id, fid):
+ print "TREMOVE (tag =", tag, ", fid =", fid, ")"
- def v9fs_wstat(self, tag, id, fid, mode, atime, mtime):
- print "TWSTAT (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", atime =", atime, "mtime =", mtime, ")"
+ def v9fs_wstat(self, tag, id, fid, mode, atime, mtime):
+ print "TWSTAT (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", atime =", atime, "mtime =", mtime, ")"
- def v9fs_mknod(self, tag, id, fid, mode, major, minor):
- print "TMKNOD (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", major =", major, ", minor =", minor, ")"
+ def v9fs_mknod(self, tag, id, fid, mode, major, minor):
+ print "TMKNOD (tag =", tag, ", fid =", fid, ", mode =", oct(mode), ", major =", major, ", minor =", minor, ")"
- def v9fs_lock(self, tag, id, fid, type, start, length):
- print "TLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
+ def v9fs_lock(self, tag, id, fid, type, start, length):
+ print "TLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
- def v9fs_lock_return(self, tag, id, status):
- print "RLOCK (tag =", tag, ", status =", status, ")"
+ def v9fs_lock_return(self, tag, id, status):
+ print "RLOCK (tag =", tag, ", status =", status, ")"
- def v9fs_getlock(self, tag, id, fid, type, start, length):
- print "TGETLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
+ def v9fs_getlock(self, tag, id, fid, type, start, length):
+ print "TGETLOCK (tag =", tag, ", fid =", fid, "type =", type, ", start =", start, ", length =", length, ")"
- def v9fs_getlock_return(self, tag, id, type, start, length, proc_id):
- print "RGETLOCK (tag =", tag, "type =", type, ", start =", start, ", length =", length, ", proc_id =", proc_id, ")"
+ def v9fs_getlock_return(self, tag, id, type, start, length, proc_id):
+ print "RGETLOCK (tag =", tag, "type =", type, ", start =", start, ", length =", length, ", proc_id =", proc_id, ")"
- def v9fs_mkdir(self, tag, id, fid, name, mode, gid):
- print "TMKDIR (tag =", tag, ", fid =", fid, ", name =", name, ", mode =", mode, ", gid =", gid, ")"
+ def v9fs_mkdir(self, tag, id, fid, name, mode, gid):
+ print "TMKDIR (tag =", tag, ", fid =", fid, ", name =", name, ", mode =", mode, ", gid =", gid, ")"
- def v9fs_mkdir_return(self, tag, id, type, version, path, err):
- print "RMKDIR (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, err =", err, ")"
+ def v9fs_mkdir_return(self, tag, id, type, version, path, err):
+ print "RMKDIR (tag =", tag, ", qid={type =", type, ", version =", version, ", path =", path, "}, err =", err, ")"
- def v9fs_xattrwalk(self, tag, id, fid, newfid, name):
- print "TXATTRWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", xattr name =", name, ")"
+ def v9fs_xattrwalk(self, tag, id, fid, newfid, name):
+ print "TXATTRWALK (tag =", tag, ", fid =", fid, ", newfid =", newfid, ", xattr name =", name, ")"
- def v9fs_xattrwalk_return(self, tag, id, size):
- print "RXATTRWALK (tag =", tag, ", xattrsize =", size, ")"
+ def v9fs_xattrwalk_return(self, tag, id, size):
+ print "RXATTRWALK (tag =", tag, ", xattrsize =", size, ")"
- def v9fs_xattrcreate(self, tag, id, fid, name, size, flags):
- print "TXATTRCREATE (tag =", tag, ", fid =", fid, ", name =", name, ", xattrsize =", size, ", flags =", flags, ")"
+ def v9fs_xattrcreate(self, tag, id, fid, name, size, flags):
+ print "TXATTRCREATE (tag =", tag, ", fid =", fid, ", name =", name, ", xattrsize =", size, ", flags =", flags, ")"
- def v9fs_readlink(self, tag, id, fid):
- print "TREADLINK (tag =", tag, ", fid =", fid, ")"
+ def v9fs_readlink(self, tag, id, fid):
+ print "TREADLINK (tag =", tag, ", fid =", fid, ")"
- def v9fs_readlink_return(self, tag, id, target):
- print "RREADLINK (tag =", tag, ", target =", target, ")"
+ def v9fs_readlink_return(self, tag, id, target):
+ print "RREADLINK (tag =", tag, ", target =", target, ")"
simpletrace.run(VirtFSRequestTracker())
diff --git a/trace-events b/trace-events
index 7f9cec4..0f0a6b0 100644
--- a/trace-events
+++ b/trace-events
@@ -554,7 +554,7 @@ open_eth_desc_read(uint32_t addr, uint32_t v) "DESC[%04x] -> %08x"
open_eth_desc_write(uint32_t addr, uint32_t v) "DESC[%04x] <- %08x"
# hw/9pfs/virtio-9p.c
-complete_pdu(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
+v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
v9fs_version(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d id %d msize %d version %s"
v9fs_version_return(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d id %d msize %d version %s"
v9fs_attach(uint16_t tag, uint8_t id, int32_t fid, int32_t afid, char* uname, char* aname) "tag %u id %u fid %d afid %d uname %s aname %s"
--
1.7.5.4
^ permalink raw reply related
* Re: NFS4 client blocked (kernel 3.0.4)
From: Trond Myklebust @ 2011-10-24 9:39 UTC (permalink / raw)
To: David Flynn; +Cc: linux-nfs
In-Reply-To: <20111022082838.GB32587@rd.bbc.co.uk>
On Sat, 2011-10-22 at 08:28 +0000, David Flynn wrote:
> Dear all,
>
> When mounting a solaris NFS4 export on a v3.0.4 client, we've experienced
> processes becoming blocked. Any further attempt to access the mountpoint
> from another process also blocks. Other mountpoints are unaffected.
> I have not identified a test case to reproduce the behaviour.
>
> Any thoughts on the matter would be most welcome,
>
> Kind regards,
>
> ..david
>
> from /proc/mounts:
> home:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.29.190.20,minorversion=0,local_lock=none,addr=172.29.120.140 0 0
>
> [105121.204200] INFO: task bash:4457 blocked for more than 120 seconds.
> [105121.247424] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [105121.299955] bash D ffffffff818050a0 0 4457 1 0x00000000
> [105121.347840] ffff8802954b5c28 0000000000000082 ffff8802954b5db8 0000000000012a40
> [105121.397793] ffff8802954b5fd8 0000000000012a40 ffff8802954b4000 0000000000012a40
> [105121.441724] 0000000000012a40 0000000000012a40 ffff8802954b5fd8 0000000000012a40
> [105121.441728] Call Trace:
> [105121.441740] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> [105121.441744] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> [105121.441746] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> [105121.441749] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> [105121.441751] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> [105121.441756] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> [105121.441759] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> [105121.441761] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> [105121.441786] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> [105121.441789] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> [105121.441791] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> [105121.441793] [<ffffffff8111050b>] filemap_fdatawait+0x2b/0x30
> [105121.441795] [<ffffffff81112124>] filemap_write_and_wait+0x44/0x60
> [105121.441803] [<ffffffffa0232805>] nfs_getattr+0x105/0x120 [nfs]
> [105121.441806] [<ffffffff81605e88>] ? do_page_fault+0x258/0x550
> [105121.441810] [<ffffffff81175b31>] vfs_getattr+0x51/0x120
> [105121.441812] [<ffffffff81175c70>] vfs_fstatat+0x70/0x90
> [105121.441814] [<ffffffff81175ccb>] vfs_stat+0x1b/0x20
> [105121.441816] [<ffffffff81175f14>] sys_newstat+0x24/0x40
> [105121.441820] [<ffffffff8101449a>] ? init_fpu+0x4a/0x150
> [105121.441822] [<ffffffff81602955>] ? page_fault+0x25/0x30
> [105121.441825] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
> [105121.441837] INFO: task bash:5612 blocked for more than 120 seconds.
> [105121.441838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [105121.441840] bash D 0000000000000005 0 5612 1 0x00000000
> [105121.441843] ffff8801f25d5ca8 0000000000000086 ffff8800163e9b08 0000000000012a40
> [105121.441845] ffff8801f25d5fd8 0000000000012a40 ffff8801f25d4000 0000000000012a40
> [105121.441848] 0000000000012a40 0000000000012a40 ffff8801f25d5fd8 0000000000012a40
> [105121.441850] Call Trace:
> [105121.441853] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> [105121.441855] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> [105121.441857] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> [105121.441859] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> [105121.441861] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> [105121.441863] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> [105121.441866] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> [105121.441868] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> [105121.441876] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> [105121.441878] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> [105121.441880] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> [105121.441882] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
> [105121.441886] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
> [105121.441888] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
> [105121.441894] [<ffffffffa022ec74>] nfs_file_flush+0x54/0x80 [nfs]
> [105121.441898] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
> [105121.441900] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
> [105121.441902] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
Does 'echo 0 >/proc/sys/sunrpc/rpc_debug' show anything being stuck in
the RPC layer?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-10-24 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024092411.GE8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 11:24:11AM +0200, Grant Likely wrote:
> To follow up from my earlier comment, this .dts structure looks fine
> and reasonable to me, and it would also be fine for the mc13892 driver
> to use for_each_child_of_node() to find all the children of the
> regulators node. Even finding the 'regulators' node by name from the
> mc13892 driver is perfectly fine provided for_each_child_of_node is
> used to find it. All of this is okay because it is under the umbrella
> of the "fsl,mc13892" binding.
Yes, a search of children of the device node that the driver is probing
off seems like a sensible approach.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-10-24 9:39 UTC (permalink / raw)
To: Grant Likely
Cc: Shawn Guo, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024092411.GE8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 11:24:11AM +0200, Grant Likely wrote:
> To follow up from my earlier comment, this .dts structure looks fine
> and reasonable to me, and it would also be fine for the mc13892 driver
> to use for_each_child_of_node() to find all the children of the
> regulators node. Even finding the 'regulators' node by name from the
> mc13892 driver is perfectly fine provided for_each_child_of_node is
> used to find it. All of this is okay because it is under the umbrella
> of the "fsl,mc13892" binding.
Yes, a search of children of the device node that the driver is probing
off seems like a sensible approach.
^ permalink raw reply
* Re: Possible diff regression in v1.7.6-473-g27af01d
From: Thomas Rast @ 2011-10-24 9:38 UTC (permalink / raw)
To: Franz Schrober
Cc: git@vger.kernel.org, marat@slonopotamus.org, rctay89@gmail.com,
gitster@pobox.com
In-Reply-To: <1319448227.70497.YahooMailNeo@web29402.mail.ird.yahoo.com>
Franz Schrober wrote:
> Hi,
>
> I am using git to manage some patches on top of the actual upstream files, but noticed that the result of git-format-patch changed between 4bfe7cb6668c43c1136304bbb17eea1b3ddf0237 and 27af01d552331eacf1ed2671b2b4b6ad4c268106
>
> I've attached two input files (I tried to provide a minimal example... I am not sure if a smaller example is possible but at least both files are smaller than 10 lines) and the results with version 1.7.6.3 and and 1.7.7. The diffs were created using: git diff anonymized_orig anonymized_new
>
> My .gitconfig file is empty.
I'm not sure why you call this a regression. For the benefit of
people who hate saving attachments, you used
$ paste anonymized_orig anonymized_new | xclip
0 1
0 2
0 0
0 3
4
5
6
7
the old diff was
--- a/anonymized_orig
+++ b/anonymized_new
@@ -1,4 +1,8 @@
-0
-0
-0
-0
+1
+2
+0
+3
+4
+5
+6
+7
and the new diff is
--- a/anonymized_orig
+++ b/anonymized_new
@@ -1,4 +1,8 @@
+1
+2
0
-0
-0
-0
+3
+4
+5
+6
+7
So the new diff correctly represents the change, and on top of that is
shorter (by only one line, admittedly). What makes it a regression?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: currently missing kernel devel trees
From: Stephen Rothwell @ 2011-10-24 9:38 UTC (permalink / raw)
To: Mike Frysinger; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <CAMjpGUe+jgnpB4pPhSBV=zYgNSUTzWYa2_KmPuWhjZw_6zjLMw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
Hi Mike,
On Sat, 15 Oct 2011 13:57:11 -0400 Mike Frysinger <vapier.adi@gmail.com> wrote:
>
> On Thu, Oct 13, 2011 at 23:25, Mike Frysinger wrote:
> > On Thu, Oct 13, 2011 at 02:43, Stephen Rothwell wrote:
> >> blackfin
> >
> > i was waiting for hpa to get back to me so i could get my repo enabled
> > again on git.kernel.org ... but maybe that'll take until/post LKS ?
>
> ah, got my info today. this tree should be alive again for you to merge in.
Thanks, looks good.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: c/s 23990:1c8789852eaf: xen crashes
From: Christoph Egger @ 2011-10-24 9:38 UTC (permalink / raw)
To: Jan Beulich; +Cc: Keir, xen-devel@lists.xensource.com, Fraser
In-Reply-To: <4EA1975F020000780005CC86@nat28.tlf.novell.com>
On 10/21/11 16:01, Jan Beulich wrote:
>>>> On 21.10.11 at 14:29, Christoph Egger<Christoph.Egger@amd.com> wrote:
>> c/s 23990:1c8789852eaf crashes xen due to a NULL pointer dereference
>> within the xen kernel.
>
> Would you be able to give the patch I just sent a try before I commit it?
>
With this patch I can no longer reproduce the crash.
Christoph
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH V2 02/11] libxl_json, Check the parser status before to call parse_complete
From: Ian Campbell @ 2011-10-24 9:38 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Xen Devel, Stefano Stabellini
In-Reply-To: <1319133573-25891-3-git-send-email-anthony.perard@citrix.com>
On Thu, 2011-10-20 at 18:59 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> tools/libxl/libxl_json.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 11f65fc..c743114 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -744,7 +744,9 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
> yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
> }
> status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
> - status = yajl_parse_complete(yajl_ctx.hand);
> + if (status == yajl_status_ok) {
> + status = yajl_parse_complete(yajl_ctx.hand);
> + }
>
> if (status == yajl_status_ok) {
You now have two of these checks back-to-back. I guess they could be
combined?
> libxl__json_object *o = yajl_ctx.head;
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 9:36 UTC (permalink / raw)
To: Sebastian Rasmussen; +Cc: Ulf Hansson, linux-mmc, linux-arm-kernel, Lee Jones
In-Reply-To: <CAAgDR1OT=+xgQTNwmTz=9XwzpbhjeZ6F-mxnVGhOAPSAR3JiFQ@mail.gmail.com>
On Sun, Oct 23, 2011 at 02:31:39AM +0200, Sebastian Rasmussen wrote:
> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
> this on my Snowball dev board yet.
There's also the issue that the specs call for the clock to run after
a command has completed for a certain number of cycles, and that the
clock must continue to run until the card reports not-busy after a
programming or erase cycle has completed - that can be long after the
previous command has 'completed'.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAgDR1OT=+xgQTNwmTz=9XwzpbhjeZ6F-mxnVGhOAPSAR3JiFQ@mail.gmail.com>
On Sun, Oct 23, 2011 at 02:31:39AM +0200, Sebastian Rasmussen wrote:
> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
> this on my Snowball dev board yet.
There's also the issue that the specs call for the clock to run after
a command has completed for a certain number of cycles, and that the
clock must continue to run until the card reports not-busy after a
programming or erase cycle has completed - that can be long after the
previous command has 'completed'.
^ 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.