* Re: [PATCH 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Jan Kiszka @ 2011-02-01 14:21 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Avi Kivity, kvm@vger.kernel.org, qemu-devel@nongnu.org,
Stefan Hajnoczi
In-Reply-To: <20110201141039.GA14442@amt.cnet>
On 2011-02-01 15:10, Marcelo Tosatti wrote:
> On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
>> On 2011-02-01 14:48, Marcelo Tosatti wrote:
>>> On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
>>>> On 2011-02-01 13:47, Marcelo Tosatti wrote:
>>>>> On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
>>>>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
>>>>>> checking for exit_request on vcpu entry and timer signals arriving
>>>>>> before KVM starts to catch them. Plug it by blocking both timer related
>>>>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> CC: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>>>>>> ---
>>>>>> cpus.c | 18 ++++++++++++++++++
>>>>>> 1 files changed, 18 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/cpus.c b/cpus.c
>>>>>> index fc3f222..29b1070 100644
>>>>>> --- a/cpus.c
>>>>>> +++ b/cpus.c
>>>>>> @@ -254,6 +254,10 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &set);
>>>>>> sigdelset(&set, SIG_IPI);
>>>>>> sigdelset(&set, SIGBUS);
>>>>>> +#ifndef CONFIG_IOTHREAD
>>>>>> + sigdelset(&set, SIGIO);
>>>>>> + sigdelset(&set, SIGALRM);
>>>>>> +#endif
>>>>>
>>>>> I'd prefer separate qemu_kvm_init_cpu_signals in the !IOTHREAD
>>>>> section.
>>>>
>>>> You mean to duplicate qemu_kvm_init_cpu_signals for both configurations?
>>>
>>> Yes, so to avoid #ifdefs spread.
>>
>> Would exchange some #ifdefs against ifndef _WIN32. Haven't measured the
>> delta though.
>>
>>>
>>>>>> +
>>>>>> +#ifndef CONFIG_IOTHREAD
>>>>>> + if (sigismember(&chkset, SIGIO) || sigismember(&chkset, SIGALRM)) {
>>>>>> + qemu_notify_event();
>>>>>> + }
>>>>>> +#endif
>>>>>
>>>>> Why is this necessary?
>>>>>
>>>>> You should break out of cpu_exec_all if there's a pending alarm (see
>>>>> qemu_alarm_pending()).
>>>>
>>>> qemu_alarm_pending() is not true until the signal is actually taken. The
>>>> alarm handler sets the required flags.
>>>
>>> Right. What i mean is you need to execute the signal handler inside
>>> cpu_exec_all loop (so that alarm pending is set).
>>>
>>> So, if there is a SIGALRM pending, qemu_run_timers has highest
>>> priority, not vcpu execution.
>>
>> We leave the vcpu loop (thanks to notify_event), process the signal in
>> the event loop and run the timer handler. This pattern is IMO less
>> invasive to the existing code, specifically as it is about to die
>> long-term anyway.
>
> You'll probably see poor timer behaviour on smp guests without iothread
> enabled.
>
Still checking, but that would mean the notification mechanism is broken
anyway: If IO events do not force us to process them quickly, we already
suffer from latencies in SMP mode.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Jan Kiszka @ 2011-02-01 14:21 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Stefan Hajnoczi, Avi Kivity, kvm@vger.kernel.org,
qemu-devel@nongnu.org
In-Reply-To: <20110201141039.GA14442@amt.cnet>
On 2011-02-01 15:10, Marcelo Tosatti wrote:
> On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
>> On 2011-02-01 14:48, Marcelo Tosatti wrote:
>>> On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
>>>> On 2011-02-01 13:47, Marcelo Tosatti wrote:
>>>>> On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
>>>>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
>>>>>> checking for exit_request on vcpu entry and timer signals arriving
>>>>>> before KVM starts to catch them. Plug it by blocking both timer related
>>>>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> CC: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
>>>>>> ---
>>>>>> cpus.c | 18 ++++++++++++++++++
>>>>>> 1 files changed, 18 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/cpus.c b/cpus.c
>>>>>> index fc3f222..29b1070 100644
>>>>>> --- a/cpus.c
>>>>>> +++ b/cpus.c
>>>>>> @@ -254,6 +254,10 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
>>>>>> pthread_sigmask(SIG_BLOCK, NULL, &set);
>>>>>> sigdelset(&set, SIG_IPI);
>>>>>> sigdelset(&set, SIGBUS);
>>>>>> +#ifndef CONFIG_IOTHREAD
>>>>>> + sigdelset(&set, SIGIO);
>>>>>> + sigdelset(&set, SIGALRM);
>>>>>> +#endif
>>>>>
>>>>> I'd prefer separate qemu_kvm_init_cpu_signals in the !IOTHREAD
>>>>> section.
>>>>
>>>> You mean to duplicate qemu_kvm_init_cpu_signals for both configurations?
>>>
>>> Yes, so to avoid #ifdefs spread.
>>
>> Would exchange some #ifdefs against ifndef _WIN32. Haven't measured the
>> delta though.
>>
>>>
>>>>>> +
>>>>>> +#ifndef CONFIG_IOTHREAD
>>>>>> + if (sigismember(&chkset, SIGIO) || sigismember(&chkset, SIGALRM)) {
>>>>>> + qemu_notify_event();
>>>>>> + }
>>>>>> +#endif
>>>>>
>>>>> Why is this necessary?
>>>>>
>>>>> You should break out of cpu_exec_all if there's a pending alarm (see
>>>>> qemu_alarm_pending()).
>>>>
>>>> qemu_alarm_pending() is not true until the signal is actually taken. The
>>>> alarm handler sets the required flags.
>>>
>>> Right. What i mean is you need to execute the signal handler inside
>>> cpu_exec_all loop (so that alarm pending is set).
>>>
>>> So, if there is a SIGALRM pending, qemu_run_timers has highest
>>> priority, not vcpu execution.
>>
>> We leave the vcpu loop (thanks to notify_event), process the signal in
>> the event loop and run the timer handler. This pattern is IMO less
>> invasive to the existing code, specifically as it is about to die
>> long-term anyway.
>
> You'll probably see poor timer behaviour on smp guests without iothread
> enabled.
>
Still checking, but that would mean the notification mechanism is broken
anyway: If IO events do not force us to process them quickly, we already
suffer from latencies in SMP mode.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH 00/13] ipset kernel patches v3
From: Patrick McHardy @ 2011-02-01 14:18 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel, Pablo Neira Ayuso
In-Reply-To: <1296514388-20900-1-git-send-email-kadlec@blackhole.kfki.hu>
Am 31.01.2011 23:52, schrieb Jozsef Kadlecsik:
> Hi,
>
> Here follows the updated ipset kernel patches. The list of changes compared
> to the previous one:
>
> - Separate ipset errnos completely from system ones and bump protocol
> version
> - Use better error codes in xt_set.c
> - Fix sparse warning about shadowed definition
> - bitmap:ip type: flavour specific adt functions
> - bitmap:port type: flavour specific adt functions
> - Move the type specificic attribute validation to the core
> - Use vzalloc() instead of __vmalloc()
> - Use meaningful error messages in xt_set.c
> - Constified attribute cannot be written
> - Send (N)ACK at dumping only when NLM_F_ACK is set
> - Correct the error codes: use ENOENT and EMSGSIZE
>
> [Because the protocol changed (NLM_F_ACK is used at dumping and error codes
> are changed), the protocol version number is incremented.]
>
> Best regards,
> Jozsef
>
> Jozsef Kadlecsik (13):
> NFNL_SUBSYS_IPSET id and NLA_PUT_NET* macros
> IP set core support
> bitmap:ip set type support
> bitmap:ip,mac type support
> bitmap:port set type support
> hash:ip set type support
> hash:ip,port set type support
> hash:ip,port,ip set type support
> hash:ip,port,net set type support
> hash:net set type support
> hash:net,port set type support
> list:set set type support
> "set" match and "SET" target support
Thanks Jozsef. I don't see any major issues with the API and anything
else can be changed more easily once this is in the tree, so I'll apply
everything and will probably send a few minor cleanups on top later.
^ permalink raw reply
* Re: [PATCH 17/32] scsi/ibmvstgt: use system_wq instead of vtgtd workqueue
From: FUJITA Tomonori @ 2011-02-01 14:18 UTC (permalink / raw)
To: tj
Cc: bvanassche, linux-kernel, fujita.tomonori, James.Bottomley,
linux-scsi, brking, rcj
In-Reply-To: <20110201104043.GH14211@htj.dyndns.org>
On Tue, 1 Feb 2011 11:40:43 +0100
Tejun Heo <tj@kernel.org> wrote:
> On Mon, Jan 24, 2011 at 05:24:14PM +0100, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, Jan 24, 2011 at 05:09:18PM +0100, Bart Van Assche wrote:
> > > Insertion of flush_work_sync() fixes a race - that's a good catch.
> > > flush_work_sync() should be invoked a little earlier though because
> > > the scheduled work may access the queue destroyed by the
> > > crq_queue_destroy(target) call. And the CRQ interrupt should be
> > > disabled from before flush_work_sync() is invoked until after the CRQ
> > > has been destroyed.
> >
> > Heh, I'm a bit out of my depth here. If you know what's necessary,
> > please go ahead and make the change.
> >
> > > Regarding the queue removal: I might have missed something, but why
> > > would you like to remove the vtgtd work queue ? Since the ibmvstgt
> > > driver is a storage target driver, processing latency matters. I'm
> > > afraid that switching from a dedicated queue to the global work queue
> > > will increase processing latency.
> >
> > Having a dedicated workqueue no longer makes any difference regarding
> > processing latency. Each workqueue is mere frontend to the shared
> > worker pool anyway. Dedicated workqueues are now meaningful only as
> > forward progress guarantee, attribute and/or flush domain - IOW, when
> > the workqueue needs to be used during memory reclaim, the work items
> > need to have specific attributes or certain group of work items need
> > to be flushed together. Apart from that, there's virtually no
> > difference between using the system_wq and a dedicated one. As using
> > the system one is usually simpler, it's natural to do that.
>
> Ping. Are you interested in doing the conversion?
FYI, this driver will be replaced shortly. Now I have the working
ibmvscsis driver for the new target framework. I'll submit it this
week. So this driver will be removed soon or later (if James prefer to
go through the proper Documentation/feature-removal-schedule.txt
process, it'll be for some time). You could leave this alone, I guess.
^ permalink raw reply
* Re: PCI passthrough issue
From: Ian Campbell @ 2011-02-01 14:18 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
In-Reply-To: <4D4814CE.5050303@jbfavre.org>
On Tue, 2011-02-01 at 14:12 +0000, Jean Baptiste Favre wrote:
> Le 01/02/2011 14:20, Ian Campbell a écrit :
> > >> If you restrict dom0 to >256MB but <512MB (using dom0_mem= on
> > hypervisor
> > >> command line) does the NIC work correctly in non-passedthrough form?
> > > My Xen hypervisor commandline is as follow:
> > > placeholder dom0_mem=256M dom0_max_vcpus=1 dom0_vcpus_pin loglvl=all
> > > guest_loglvl=all com1=115200,8n1 console=com1
> > >
> > > Everything works great without passthrough, but my dom0 is 64bits which
> > > may explain that (I do have this strange behaviour only with 32bits
> > > kernels).
> >
> > I don't suppose you could try installing a 32 bit OS in dom0? (e.g. as a
> > skanky hack you might fit something into your existing swap
> > partition ;-))
> I could try, but that would means breaking my test platform. Let's say I
> prefer complete other tests before :)
Sure, no problem.
> > > I did not tried changing dom0_mem param.
> > >
> > >> Similarly does the kernel running native with mem= cause the failure?
> > > Not sure I understand what you mean here.
> >
> > I meant to run the system as a native (non-Xen) system and use the
> > kernels mem= command line parameter to restrict the system to the
> > problematic amounts of memory. Really just trying to verify if something
> > is up specifically due to Xen or not. Probably needs a 32 bit
> > user/kernel to be a useful experiment.
> Ah ok. But then, running 32bits kernel with 64 bits OS will work ? (I
> didn't know 64bits kernel worked with 32bits OS before Konrad told me)
32 user on 64 kernel works, 64 user on 32 kernel does not so this will
tie in with the 32 bit test above too.
> > What do "ifconfig" or "ethtool -S" show for the device after some
> > failures. Do any of the numbers increment inline with the dropped
> > frames?
> >
> > Perhaps interestingly 85 bytes, plus the ICMP, IP and Ethernet header
> > sizes is something around 128 bytes (depending on options etc). This is
> > pure numerology but I notice that sky2 has a copybreak parameter
> > ("Receive copy threshold") which defaults to 128. I think it would be
> > worth trying 64 and 256.
> That's exactly the problem I faced with 256mb memory for my domU.
> Outgoing packets reached my gateway (tcpdump saw them on it, as well as
> replies) but incoming packets greater than 128bits were blocked
> somewhere between Xen hypervisor and domU user space (where I was
> listening traffic with tcpdump).
>
> I didn't notice the copybreak from sky2. Where can I change it ? It
> could be exactly what we're looking for from the beginning, couldn't it ?
> How can I change it ?
Assuming the driver is modular:
"modprobe sky2 copybreak=<N>"
Depending on your distro there will be somewhere in /etc you can add
this. e.g. on Debian you can create a file in /etc/modprobe.d/
containing "option sky copybreak=<N>" other distros
use /etc/modprobe.conf etc.
> > Are you able to see any traffic with tcpdump, either in guest and/or
> > from another host (may require switch configuration to allow it to see
> > the traffic). e.g. do you see the ICMP Echo Request but not the Echo
> > Response or do you see nothing at all etc.
> tcpdump tests have been done from my gateway and from domU.
> On the GW: can see all incoming packets (whatever could be the size) and
> send all replies.
> On the DomU: can see all outgoing packets but only incoming ones shorter
> than 128bytes (global size, means "ping -s85" and less)
OK, so it is the sky2 receive path which is at fault, that's very useful
info. It corresponds with the copybreak theory too.
Ian.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 14:18 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jeremy Kerr, Dima Zavin, Saravana Kannan, Lorenzo Pieralisi,
linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel,
Paul Mundt, Ben Dooks, Vincent Guittot, linux-arm-kernel,
Nicolas Pitre
In-Reply-To: <20110201131512.GH31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 01:15:12PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 11:54:49AM +0100, Uwe Kleine-König wrote:
> > Alternatively don't force the sleep in clk_prepare (e.g. by protecting
> > prepare_count by a spinlock (probably enable_lock)) and call clk_prepare
> > before calling clk->ops->enable?
>
> That's a completely bad idea. I assume you haven't thought about this
> very much.
Right, but I thought it a bit further than you did. Like the following:
int clk_prepare(struct clk *clk)
{
int ret = 0, first;
unsigned long flags;
spin_lock_irqsave(&clk->enable_lock, flags);
if (clk->flags & CLK_BUSY) {
/*
* this must not happen, please serialize calls to
* clk_prepare/clk_enable
*/
ret = -EBUSY;
goto out_unlock;
}
first = clk->prepare_count++ == 0;
if (first)
clk->flags |= CLK_BUSY;
spin_unlock_irqrestore(&clk->enable_lock, flags);
if (!first)
return 0;
if (clk->ops->prepare) {
might_sleep();
ret = clk->ops->prepare(clk);
}
spin_lock_irqsave(&clk->enable_lock, flags);
clk->flags &= ~CLK_BUSY;
if (ret)
clk->prepare_count--;
out_unlock:
spin_unlock_irqrestore(&clk->enable_lock, flags);
return ret;
}
If you now find a problem with that you can blame me not having thought
it to an end.
And note, this is only a suggestion. I.e. I don't know what is the best
to do in the case where I implemented returning -EBUSY above. BUG?
Wait for CLK_BUSY to be cleared?
I'm not sure I like "clk_prepare sleeps iff unprepared but preparable".
Still I think the approach is worth to be discussed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201131512.GH31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 01:15:12PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 11:54:49AM +0100, Uwe Kleine-K?nig wrote:
> > Alternatively don't force the sleep in clk_prepare (e.g. by protecting
> > prepare_count by a spinlock (probably enable_lock)) and call clk_prepare
> > before calling clk->ops->enable?
>
> That's a completely bad idea. I assume you haven't thought about this
> very much.
Right, but I thought it a bit further than you did. Like the following:
int clk_prepare(struct clk *clk)
{
int ret = 0, first;
unsigned long flags;
spin_lock_irqsave(&clk->enable_lock, flags);
if (clk->flags & CLK_BUSY) {
/*
* this must not happen, please serialize calls to
* clk_prepare/clk_enable
*/
ret = -EBUSY;
goto out_unlock;
}
first = clk->prepare_count++ == 0;
if (first)
clk->flags |= CLK_BUSY;
spin_unlock_irqrestore(&clk->enable_lock, flags);
if (!first)
return 0;
if (clk->ops->prepare) {
might_sleep();
ret = clk->ops->prepare(clk);
}
spin_lock_irqsave(&clk->enable_lock, flags);
clk->flags &= ~CLK_BUSY;
if (ret)
clk->prepare_count--;
out_unlock:
spin_unlock_irqrestore(&clk->enable_lock, flags);
return ret;
}
If you now find a problem with that you can blame me not having thought
it to an end.
And note, this is only a suggestion. I.e. I don't know what is the best
to do in the case where I implemented returning -EBUSY above. BUG?
Wait for CLK_BUSY to be cleared?
I'm not sure I like "clk_prepare sleeps iff unprepared but preparable".
Still I think the approach is worth to be discussed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: @ 2011-02-01 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201131512.GH31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 01:15:12PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 11:54:49AM +0100, Uwe Kleine-König wrote:
> > Alternatively don't force the sleep in clk_prepare (e.g. by protecting
> > prepare_count by a spinlock (probably enable_lock)) and call clk_prepare
> > before calling clk->ops->enable?
>
> That's a completely bad idea. I assume you haven't thought about this
> very much.
Right, but I thought it a bit further than you did. Like the following:
int clk_prepare(struct clk *clk)
{
int ret = 0, first;
unsigned long flags;
spin_lock_irqsave(&clk->enable_lock, flags);
if (clk->flags & CLK_BUSY) {
/*
* this must not happen, please serialize calls to
* clk_prepare/clk_enable
*/
ret = -EBUSY;
goto out_unlock;
}
first = clk->prepare_count++ = 0;
if (first)
clk->flags |= CLK_BUSY;
spin_unlock_irqrestore(&clk->enable_lock, flags);
if (!first)
return 0;
if (clk->ops->prepare) {
might_sleep();
ret = clk->ops->prepare(clk);
}
spin_lock_irqsave(&clk->enable_lock, flags);
clk->flags &= ~CLK_BUSY;
if (ret)
clk->prepare_count--;
out_unlock:
spin_unlock_irqrestore(&clk->enable_lock, flags);
return ret;
}
If you now find a problem with that you can blame me not having thought
it to an end.
And note, this is only a suggestion. I.e. I don't know what is the best
to do in the case where I implemented returning -EBUSY above. BUG?
Wait for CLK_BUSY to be cleared?
I'm not sure I like "clk_prepare sleeps iff unprepared but preparable".
Still I think the approach is worth to be discussed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 1/8] bluetooth: add server support
From: Frederic Danis @ 2011-02-01 14:17 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296507122-10936-1-git-send-email-padovan@profusion.mobi>
[-- Attachment #1: Type: text/plain, Size: 8172 bytes --]
Hello Gustavo,
Le 31/01/2011 21:51, Gustavo F. Padovan a écrit :
> Initial code to have support to listen over a RFCOMM socket for incoming
> connections.
> ---
> Makefile.am | 1 +
> plugins/bluetooth.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++++
> plugins/bluetooth.h | 11 ++++
> 3 files changed, 177 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index a38fcb9..77b1453 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -321,6 +321,7 @@ builtin_sources += plugins/bluetooth.c plugins/bluetooth.h
> builtin_modules += hfp
> builtin_sources += plugins/hfp.c plugins/bluetooth.h
>
> +builtin_sources += $(btio_sources)
> builtin_cflags += @BLUEZ_CFLAGS@
> builtin_libadd += @BLUEZ_LIBS@
> endif
> diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
> index 93dd7a1..dcf75e6 100644
> --- a/plugins/bluetooth.c
> +++ b/plugins/bluetooth.c
> @@ -35,13 +35,58 @@
>
> #include<ofono/dbus.h>
>
> +#include<btio.h>
> #include "bluetooth.h"
>
> static DBusConnection *connection;
> static GHashTable *uuid_hash = NULL;
> static GHashTable *adapter_address_hash = NULL;
> +static GSList *server_list = NULL;
> static gint bluetooth_refcount;
>
> +struct server {
> + guint16 service;
> + gchar *name;
> + guint8 channel;
> + GIOChannel *io;
> + char *adapter;
> + guint handle;
> + ConnectFunc connect_cb;
> + gpointer user_data;
> +};
> +
> +typedef struct {
> + guint8 b[6];
> +} __attribute__((packed)) bdaddr_t;
> +
> +static void baswap(bdaddr_t *dst, const bdaddr_t *src)
> +{
> + register unsigned char *d = (unsigned char *) dst;
> + register const unsigned char *s = (const unsigned char *) src;
> + register int i;
> +
> + for (i = 0; i< 6; i++)
> + d[i] = s[5-i];
> +}
> +
> +static int str2ba(const char *str, bdaddr_t *ba)
> +{
> + guint8 b[6];
> + const char *ptr = str;
> + int i;
> +
> + for (i = 0; i< 6; i++) {
> + b[i] = (guint8) strtol(ptr, NULL, 16);
> + if (i != 5&& !(ptr = strchr(ptr, ':')))
> + ptr = ":00:00:00:00:00";
> + ptr++;
> + }
> +
> + baswap(ba, (bdaddr_t *) b);
> +
> + return 0;
> +}
> +
> void bluetooth_create_path(const char *dev_addr, const char *adapter_addr,
> char *buf, int size)
> {
> @@ -371,6 +416,70 @@ static gboolean property_changed(DBusConnection *connection, DBusMessage *msg,
> return TRUE;
> }
>
> +static void server_stop(gpointer data)
> +{
> + struct server *server = data;
> +
> + if (server->handle> 0) {
> + DBusMessage *msg;
> +
> + msg = dbus_message_new_method_call(BLUEZ_SERVICE,
> + server->adapter,
> + BLUEZ_SERVICE_INTERFACE,
> + "RemoveRecord");
> + dbus_message_append_args(msg, DBUS_TYPE_UINT32,&server->handle,
> + DBUS_TYPE_INVALID);
> + g_dbus_send_message(connection, msg);
> +
> + server->handle = 0;
> + }
> +
> + if (server->io != NULL) {
> + g_io_channel_shutdown(server->io, TRUE, NULL);
> + g_io_channel_unref(server->io);
> + server->io = NULL;
> + }
> +
> + g_free(server->adapter);
> + server->adapter = NULL;
> +}
> +
> +static void new_connection(GIOChannel *io, gpointer user_data)
> +{
> + struct server *server = user_data;
> +
> + DBG("%p", server);
> +}
> +
> +static void server_start(gpointer data, gpointer user_data)
> +{
> + struct server *server = data;
> + char *addr, *path = user_data;
> + bdaddr_t baddr;
> + GError *err = NULL;
> +
> + if (server->handle != 0)
> + return;
> +
> + addr = g_hash_table_lookup(adapter_address_hash, path);
> + str2ba(addr,&baddr);
> + server->io = bt_io_listen(BT_IO_RFCOMM, NULL, new_connection,
> + server, NULL,&err,
> + BT_IO_OPT_SOURCE_BDADDR,&baddr,
> + BT_IO_OPT_CHANNEL, server->channel,
> + BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM,
> + BT_IO_OPT_INVALID);
> + if (server->io == NULL) {
> + ofono_error("Bluetooth %s register failed: %s",
> + server->name, err->message);
> + g_error_free(err);
> + server_stop(server);
> + return;
> + }
> +
> + server->adapter = g_strdup(path);
> +}
> +
This will not allows to start server on multiple adapters, as the test
of the SDP Record handle will prevent to bt_io_listen on other adapters.
I do not understand why you pass the adapter address, if it is omitted
the bt_io_listen will be done for all adapters.
> static void adapter_properties_cb(DBusPendingCall *call, gpointer user_data)
> {
> const char *path = user_data;
> @@ -395,6 +504,9 @@ static void adapter_properties_cb(DBusPendingCall *call, gpointer user_data)
> g_hash_table_insert(adapter_address_hash,
> g_strdup(path), g_strdup(addr));
>
> + if (server_list)
> + g_slist_foreach(server_list, server_start, (gpointer)path);
> +
> for (l = device_list; l; l = l->next) {
> const char *device = l->data;
>
> @@ -429,11 +541,26 @@ static gboolean adapter_removed(DBusConnection *connection,
> DBusMessage *message, void *user_data)
> {
> const char *path;
> + GSList *l;
>
> if (dbus_message_get_args(message, NULL, DBUS_TYPE_OBJECT_PATH,&path,
> DBUS_TYPE_INVALID) == TRUE)
> g_hash_table_remove(adapter_address_hash, path);
>
> + for (l = server_list; l; l = l->next) {
> + struct server *server = l->data;
> +
> + if (!server->adapter)
> + continue;
> +
> + if (!g_str_equal(path, server->adapter))
> + continue;
> +
> + /* Don't remove handle if the adapter has been removed */
> + server->handle = 0;
> + server_stop(server);
> + }
> +
> return TRUE;
> }
>
> @@ -590,5 +717,43 @@ void bluetooth_unregister_uuid(const char *uuid)
> bluetooth_unref();
> }
>
> +struct server *bluetooth_register_server(guint16 service, char *name,
> + guint8 channel, ConnectFunc cb,
> + gpointer user_data)
> +{
> + struct server *server;
> +
> + server = g_try_new0(struct server, 1);
> + if (!server)
> + return NULL;
> +
> + bluetooth_ref();
> +
> + server->service = service;
> + server->name = g_strdup(name);
> + server->channel = channel;
> + server->connect_cb = cb;
> + server->user_data = user_data;
> +
> + server_list = g_slist_prepend(server_list, server);
> +
> + bluetooth_send_with_reply("/", BLUEZ_MANAGER_INTERFACE, "GetProperties",
> + manager_properties_cb, NULL, NULL, -1,
> + DBUS_TYPE_INVALID);
> +
> + return server;
> +}
> +
> +void bluetooth_unregister_server(struct server *server)
> +{
> + server_list = g_slist_remove(server_list, server);
> +
> + server_stop(server);
> + g_free(server->name);
> + g_free(server);
> +
> + bluetooth_unref();
> +}
> +
> OFONO_PLUGIN_DEFINE(bluetooth, "Bluetooth Utils Plugins", VERSION,
> OFONO_PLUGIN_PRIORITY_DEFAULT, NULL, NULL)
> diff --git a/plugins/bluetooth.h b/plugins/bluetooth.h
> index 42b0d13..f6fc6a6 100644
> --- a/plugins/bluetooth.h
> +++ b/plugins/bluetooth.h
> @@ -23,6 +23,7 @@
> #define BLUEZ_MANAGER_INTERFACE BLUEZ_SERVICE ".Manager"
> #define BLUEZ_ADAPTER_INTERFACE BLUEZ_SERVICE ".Adapter"
> #define BLUEZ_DEVICE_INTERFACE BLUEZ_SERVICE ".Device"
> +#define BLUEZ_SERVICE_INTERFACE BLUEZ_SERVICE ".Service"
>
> #define DBUS_TIMEOUT 15
>
> @@ -39,10 +40,20 @@ struct bluetooth_profile {
> void (*set_alias)(const char *device, const char *);
> };
>
> +
> +typedef void (*ConnectFunc)(GIOChannel *io, GError *err, gpointer user_data);
> +
> +struct server;
> +
> int bluetooth_register_uuid(const char *uuid,
> struct bluetooth_profile *profile);
> void bluetooth_unregister_uuid(const char *uuid);
>
> +struct server *bluetooth_register_server(guint16 service, char *name,
> + guint8 channel, ConnectFunc cb,
> + gpointer user_data);
> +void bluetooth_unregister_server(struct server *server);
> +
> void bluetooth_create_path(const char *dev_addr, const char *adapter_addr,
> char *buf, int size);
>
--
Frederic Danis Open Source Technology Centre
frederic.danis(a)intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] ARM: tegra: Add to struct harmony_audio_platform_data
From: Mark Brown @ 2011-02-01 14:17 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-tegra, alsa-devel, lrg
In-Reply-To: <1296513435-14792-1-git-send-email-swarren@nvidia.com>
On Mon, Jan 31, 2011 at 03:37:15PM -0700, Stephen Warren wrote:
> Add fields to describe all the audio-related GPIOs on Harmony, except for
> the codec's GPIO IRQ, which will be passed in its i2c_board_info.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v4 1/4] drivers: hwspinlock: add framework
From: Greg KH @ 2011-02-01 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110131223859.27169db0.akpm@linux-foundation.org>
On Mon, Jan 31, 2011 at 10:38:59PM -0800, Andrew Morton wrote:
> On Tue, 1 Feb 2011 08:20:13 +0200 Ohad Ben-Cohen <ohad@wizery.com> wrote:
>
> > On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > It's a little irritating having two hwspinlock.h's.
> > > hwspinlock_internal.h wold be a conventional approach. __But it's not a
> > > big deal.
> > ...
> >
> > >> +/**
> > >> + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
> > >> + * @hwlock: the hwspinlock to be locked
> > >> + * @timeout: timeout value in jiffies
> > >
> > > hm, why in jiffies?
> > >
> > > The problem here is that lazy programmers will use
> > >
> > > __ __ __ __hwspin_lock_timeout(lock, 10, ...)
> > >
> > > and their code will work happily with HZ=100 but will explode with HZ=1000.
> > >
> > > IOW, this interface *requires* that all callers perform a
> > > seconds-to-jiffies conversion before calling hwspin_lock_timeout(). __So
> > > why not reduce their effort and their ability to make mistakes by
> > > defining the API to take seconds?
> >
> > I considered that, but then decided to use jiffies in order to be
> > consistent with wait_event_timeout/schedule_timeout (although I don't
> > return the remaining jiffies in case the lock is taken before the
> > timeout elapses), and also to allow user-selected granularity.
> >
> > But I do kind of like the idea of not using jiffies. We can probably
> > even move to msecs, since anyway this is an error condition, and
> > people who needs a quick check should just use the trylock() version.
> >
> > I'll do a quick respin of the patches with that and the
> > hwspinlock_internal.h comment above.
>
> OK..
>
> The patch series looks OK to me. But there isn't a lot of point in me
> putting them into my tree. Maybe Tony or Russell or Greg can grab them
> if they like the look of it all?
As it's an arm-specific thing, it should probably go through Russell's
tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/4] drivers: hwspinlock: add framework
From: Greg KH @ 2011-02-01 14:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Ohad Ben-Cohen, linux-omap, linux-kernel, linux-arm-kernel,
Tony Lindgren, Benoit Cousson, Grant Likely, Suman Anna,
Kevin Hilman, Arnd Bergmann, Paul Walmsley, Hari Kanigeri,
Simon Que, Russell King
In-Reply-To: <20110131223859.27169db0.akpm@linux-foundation.org>
On Mon, Jan 31, 2011 at 10:38:59PM -0800, Andrew Morton wrote:
> On Tue, 1 Feb 2011 08:20:13 +0200 Ohad Ben-Cohen <ohad@wizery.com> wrote:
>
> > On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > It's a little irritating having two hwspinlock.h's.
> > > hwspinlock_internal.h wold be a conventional approach. __But it's not a
> > > big deal.
> > ...
> >
> > >> +/**
> > >> + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit
> > >> + * @hwlock: the hwspinlock to be locked
> > >> + * @timeout: timeout value in jiffies
> > >
> > > hm, why in jiffies?
> > >
> > > The problem here is that lazy programmers will use
> > >
> > > __ __ __ __hwspin_lock_timeout(lock, 10, ...)
> > >
> > > and their code will work happily with HZ=100 but will explode with HZ=1000.
> > >
> > > IOW, this interface *requires* that all callers perform a
> > > seconds-to-jiffies conversion before calling hwspin_lock_timeout(). __So
> > > why not reduce their effort and their ability to make mistakes by
> > > defining the API to take seconds?
> >
> > I considered that, but then decided to use jiffies in order to be
> > consistent with wait_event_timeout/schedule_timeout (although I don't
> > return the remaining jiffies in case the lock is taken before the
> > timeout elapses), and also to allow user-selected granularity.
> >
> > But I do kind of like the idea of not using jiffies. We can probably
> > even move to msecs, since anyway this is an error condition, and
> > people who needs a quick check should just use the trylock() version.
> >
> > I'll do a quick respin of the patches with that and the
> > hwspinlock_internal.h comment above.
>
> OK..
>
> The patch series looks OK to me. But there isn't a lot of point in me
> putting them into my tree. Maybe Tony or Russell or Greg can grab them
> if they like the look of it all?
As it's an arm-specific thing, it should probably go through Russell's
tree.
thanks,
greg k-h
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Lukasz Rymanowski @ 2011-02-01 14:16 UTC (permalink / raw)
To: roystonr
Cc: Luiz Augusto von Dentz, Johan Hedberg, linux-bluetooth, skrovvid,
rshaffer
In-Reply-To: <2ec0d2a2febdbcf4ab73812ad709f542.squirrel@www.codeaurora.org>
Hi Roystonr,
> Have provided the patch to the tester to verify as we don't have the BMW
> CK available locally. Would update the feedback received.
I'm just wondering, Is it working for you ?
>
> Regards,
> Royston Rodrigues
>
Regards
\Lukasz
^ permalink raw reply
* [PATCH] NFSD: memory corruption due to writing beyond the stat array
From: Konstantin Khorenko @ 2011-02-01 14:16 UTC (permalink / raw)
To: J. Bruce Fields, Neil Brown; +Cc: linux-nfs, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
Hi All,
i've found a bug which makes NFSD to corrupt memory due to writing beyond the stat array.
Initially this issue was found on 2.6.18-x RHEL5 kernel, but the same seems to be true for the current mainstream kernel (checked on 2.6.38-rc3).
./fs/nfsd/vfs.c:
static inline struct raparms *
nfsd_get_raparms(dev_t dev, ino_t ino)
{
...
// here we searched our file in a readahead cache
// but not found it
...
depth = nfsdstats.ra_size*11/10;
...
// some stuff, but "depth" is not changed
...
nfsdstats.ra_depth[depth*10/nfsdstats.ra_size]++;
...
}
And here we write to the 12th array element
(nfsdstats.ra_size*11/10*10/nfsdstats.ra_size == 11), while ra_depth has only
11 elements:
struct nfsd_stats {
...
unsigned int ra_depth[11]; /* number of times ra entry was found that deep
* in the cache (10percentiles). [10] = not found */
#ifdef CONFIG_NFSD_V4
unsigned int nfs4_opcount[LAST_NFS4_OP + 1]; /* count of individual
nfsv4 operations */
#endif
};
This means that each time we did not find a file in a readahead cache we
corrupt memory. Fortunately in a kernel with NFSDv4 compiled in it corrupts
(inc) NFS4 ops counter, but in a kernel with NFSDv4 disabled it corrupts (inc)
some other data, that lays in the memory beyond nfsdstats.
Proposed fix is attached.
--
Best regards,
Konstantin Khorenko
[-- Attachment #2: diff-ms-nfsd-write-beyond-stat-array --]
[-- Type: text/plain, Size: 892 bytes --]
NFSD: The patch fixes writing beyond the array.
If nfsd fails to find an exported via NFS file in the readahead cache,
it should increment corresponding nfsdstats counter (ra_depth[10]), but
due to a bug writes beside the stat array, corrupting following field.
In a kernel with NFSDv4 compiled in it corrupts (inc) NFS4 counter:
the number of individual nfsv4 operations.
In a kernel with NFSDv4 disabled it corrupts (inc) some other data,
that lays in the memory beyond nfsdstats.
Signed-off-by: Konstantin Khorenko <khorenko@openvz.org>
--- a/fs/nfsd/vfs.c.nfsd 2011-01-05 03:50:19.000000000 +0300
+++ b/fs/nfsd/vfs.c 2011-02-01 16:39:28.000000000 +0300
@@ -809,7 +809,7 @@ nfsd_get_raparms(dev_t dev, ino_t ino)
if (ra->p_count == 0)
frap = rap;
}
- depth = nfsdstats.ra_size*11/10;
+ depth = nfsdstats.ra_size;
if (!frap) {
spin_unlock(&rab->pb_lock);
return NULL;
^ permalink raw reply
* Re: [Resend] [PATCH] ASoC: Amstrad Delta: fix const related build error
From: Mark Brown @ 2011-02-01 14:16 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: alsa-devel, Liam Girdwood
In-Reply-To: <201102011111.56190.jkrzyszt@tis.icnet.pl>
On Tue, Feb 01, 2011 at 11:11:55AM +0100, Janusz Krzysztofik wrote:
> The Amstrad Delta ASoC driver used to override the digital_mute()
> callback, expected to be not provided by the on-board CX20442 CODEC
> driver, with its own implementation. While this is still posssible when
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] hrtimers: Add CLOCK_BOOTTIME clockid, hrtimerbase and posix interface
From: Thomas Gleixner @ 2011-02-01 14:16 UTC (permalink / raw)
To: John Stultz
Cc: LKML, Jamie Lokier, Alexander Shishkin, Arve Hjønnevåg
In-Reply-To: <1296531837-12879-3-git-send-email-john.stultz@linaro.org>
On Mon, 31 Jan 2011, John Stultz wrote:
> CLOCK_MONOTONIC stops while the system is in suspend. This is because
> to applications system suspend is invisible. However, there is a
> growing set of applications that are wanting to be suspend-aware,
> but do not want to deal with the complicatoins of CLOCK_REALTIME
> (which might jump around if settimeofday is called).
>
> For these applications, I propose a new clockid: CLOCK_BOOTTIME.
> CLOCK_BOOTTIME is idential to CLOCK_MONOTONIC, except it also
> includes any time spent in suspend.
>
> This patch adds the new CLOCK_BOOTTIME clockid, as well as the
> infrastructure needed to support hrtimers against it, and the
> wiring to expose it out via the posix interface.
Can you please split that into parts:
- Add the new functions
- Wire up hrtimers, posix-timers
> static void hrtimer_get_softirq_time(struct hrtimer_cpu_base *base)
> {
> - ktime_t xtim, tomono;
> - struct timespec xts, tom;
> + ktime_t xtim, tomono, sleep;
> + struct timespec xts, tom, slp;
> unsigned long seq;
>
> do {
> seq = read_seqbegin(&xtime_lock);
> xts = __current_kernel_time();
> tom = __get_wall_to_monotonic();
> + slp = __get_sleep_time();
> } while (read_seqretry(&xtime_lock, seq));
Hmm, that conflicts with the xtime_lock cleanup in tip/timers/core.
> /*
> * Initialize everything, well, just everything in Posix clocks/timers ;)
> */
> @@ -301,12 +309,18 @@ static __init int init_posix_timers(void)
> .timer_create = no_timer_create,
> .nsleep = no_nsleep,
> };
> + struct k_clock clock_boottime = {
> + .clock_getres = hrtimer_get_res,
> + .clock_get = posix_get_boottime,
> + .clock_set = do_posix_clock_nosettime,
That's going to conflict with the posix timer cleanup, but it's easy enough to fix.
Thanks,
tglx
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] virtagent - fsfreeze support
From: Stefan Hajnoczi @ 2011-02-01 14:16 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: agl, qemu-devel, mdroth
In-Reply-To: <1296557928-30019-1-git-send-email-Jes.Sorensen@redhat.com>
On Tue, Feb 1, 2011 at 10:58 AM, <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> This is a first attempt to add fsfreeze support to virtagent. The idea
> is for the guest agent to walk the list of locally mounted file
> systems in the guest, and issuing an ioctl to freeze them. The host
> can then do a live snapshot of the guest, obtaining stable file
> systems. After the snapshot, the host then calls the thaw function in
> virtagent, which goes through the list of previously frozen file
> systems and unfreezes them.
Any plans for a call-out to pre/post freeze and thaw scripts so that
applications can flush cached data to disk and brace themselves for
freeze?
Stefan
^ permalink raw reply
* [PATCH] drm: Remove unused variable
From: Chris Wilson @ 2011-02-01 14:15 UTC (permalink / raw)
To: dri-devel
The name[64] was only used in the error message, but never set.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/drm_debugfs.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 9d8c892..2631c00 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -90,7 +90,6 @@ int drm_debugfs_create_files(struct drm_info_list *files, int count,
struct drm_device *dev = minor->dev;
struct dentry *ent;
struct drm_info_node *tmp;
- char name[64];
int i, ret;
for (i = 0; i < count; i++) {
@@ -108,8 +107,8 @@ int drm_debugfs_create_files(struct drm_info_list *files, int count,
ent = debugfs_create_file(files[i].name, S_IFREG | S_IRUGO,
root, tmp, &drm_debugfs_fops);
if (!ent) {
- DRM_ERROR("Cannot create /sys/kernel/debug/dri/%s/%s\n",
- name, files[i].name);
+ DRM_ERROR("Cannot create /sys/kernel/debug/dri/.../%s\n",
+ files[i].name);
kfree(tmp);
ret = -1;
goto fail;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] ARM: add PrimeCell generic DMA to MMCI/PL180
From: Linus Walleij @ 2011-02-01 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201133036.GI31216@n2100.arm.linux.org.uk>
2011/2/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> So, the solutions as I see it are:
>
> 1. If DMAREQCTL = 1, move the burst limiting work-around into the DMA
> ? engine driver, if it really is a problem.
>
> 2. Set DMAREQCTL = 0.
>
> (2) seems to be the most sane solution to me.
Let's go with that as indicated in other mail.
However the DMAREQCTL is an odd beast and I just cannot
wrap my head around it. It certainly isn't there to solve any
software problems, so I need to find some usecase for it.
Generating SDIO traffic with odd bytechunks isn't that easy
though.
Linus Walleij
^ permalink raw reply
* Re: [PATCH] ath9k: Fix memory leak due to failed PAPRD frames
From: John W. Linville @ 2011-02-01 14:05 UTC (permalink / raw)
To: Mohammed Shafi
Cc: Luis R. Rodriguez, Mohammed Shajakhan,
linux-wireless@vger.kernel.org
In-Reply-To: <4D478F12.1070404@atheros.com>
On Tue, Feb 01, 2011 at 10:11:54AM +0530, Mohammed Shafi wrote:
> On Tuesday 01 February 2011 12:13 AM, Luis R. Rodriguez wrote:
> >On Sun, Jan 30, 2011 at 11:55 PM, Mohammed Shafi Shajakhan
> ><mshajakhan@atheros.com> wrote:
> >>From: Mohammed Shafi Shajakhan<mshajakhan@atheros.com>
> >>
> >>free the skb's when the Tx of PAPRD frames fails and also add a debug
> >>message indicating that.
> >>
> >>Signed-off-by: Mohammed Shafi Shajakhan<mshajakhan@atheros.com>
> >Is this a stable fix?
> No Luis, this problem came from some recent changes in PAPRD before
> that it was Ok.
The patch applied to wireless-2.6 without changes, and the error
handling for ath_tx_start matched existing usage. So, I have it
queued now in wireless-2.6 with an added "Cc: stable@kernel.org".
Should I not?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Marcelo Tosatti @ 2011-02-01 14:10 UTC (permalink / raw)
To: Jan Kiszka
Cc: Stefan Hajnoczi, Avi Kivity, kvm@vger.kernel.org,
qemu-devel@nongnu.org
In-Reply-To: <4D48116A.9020807@siemens.com>
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
> On 2011-02-01 14:48, Marcelo Tosatti wrote:
> > On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
> >> On 2011-02-01 13:47, Marcelo Tosatti wrote:
> >>> On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
> >>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
> >>>> checking for exit_request on vcpu entry and timer signals arriving
> >>>> before KVM starts to catch them. Plug it by blocking both timer related
> >>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
> >>>>
> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> CC: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> >>>> ---
> >>>> cpus.c | 18 ++++++++++++++++++
> >>>> 1 files changed, 18 insertions(+), 0 deletions(-)
> >>>>
> >>>> diff --git a/cpus.c b/cpus.c
> >>>> index fc3f222..29b1070 100644
> >>>> --- a/cpus.c
> >>>> +++ b/cpus.c
> >>>> @@ -254,6 +254,10 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
> >>>> pthread_sigmask(SIG_BLOCK, NULL, &set);
> >>>> sigdelset(&set, SIG_IPI);
> >>>> sigdelset(&set, SIGBUS);
> >>>> +#ifndef CONFIG_IOTHREAD
> >>>> + sigdelset(&set, SIGIO);
> >>>> + sigdelset(&set, SIGALRM);
> >>>> +#endif
> >>>
> >>> I'd prefer separate qemu_kvm_init_cpu_signals in the !IOTHREAD
> >>> section.
> >>
> >> You mean to duplicate qemu_kvm_init_cpu_signals for both configurations?
> >
> > Yes, so to avoid #ifdefs spread.
>
> Would exchange some #ifdefs against ifndef _WIN32. Haven't measured the
> delta though.
>
> >
> >>>> +
> >>>> +#ifndef CONFIG_IOTHREAD
> >>>> + if (sigismember(&chkset, SIGIO) || sigismember(&chkset, SIGALRM)) {
> >>>> + qemu_notify_event();
> >>>> + }
> >>>> +#endif
> >>>
> >>> Why is this necessary?
> >>>
> >>> You should break out of cpu_exec_all if there's a pending alarm (see
> >>> qemu_alarm_pending()).
> >>
> >> qemu_alarm_pending() is not true until the signal is actually taken. The
> >> alarm handler sets the required flags.
> >
> > Right. What i mean is you need to execute the signal handler inside
> > cpu_exec_all loop (so that alarm pending is set).
> >
> > So, if there is a SIGALRM pending, qemu_run_timers has highest
> > priority, not vcpu execution.
>
> We leave the vcpu loop (thanks to notify_event), process the signal in
> the event loop and run the timer handler. This pattern is IMO less
> invasive to the existing code, specifically as it is about to die
> long-term anyway.
You'll probably see poor timer behaviour on smp guests without iothread
enabled.
^ permalink raw reply
* Re: [PATCH 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Marcelo Tosatti @ 2011-02-01 14:10 UTC (permalink / raw)
To: Jan Kiszka
Cc: Avi Kivity, kvm@vger.kernel.org, qemu-devel@nongnu.org,
Stefan Hajnoczi
In-Reply-To: <4D48116A.9020807@siemens.com>
On Tue, Feb 01, 2011 at 02:58:02PM +0100, Jan Kiszka wrote:
> On 2011-02-01 14:48, Marcelo Tosatti wrote:
> > On Tue, Feb 01, 2011 at 02:32:38PM +0100, Jan Kiszka wrote:
> >> On 2011-02-01 13:47, Marcelo Tosatti wrote:
> >>> On Thu, Jan 27, 2011 at 02:09:58PM +0100, Jan Kiszka wrote:
> >>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
> >>>> checking for exit_request on vcpu entry and timer signals arriving
> >>>> before KVM starts to catch them. Plug it by blocking both timer related
> >>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
> >>>>
> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> CC: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
> >>>> ---
> >>>> cpus.c | 18 ++++++++++++++++++
> >>>> 1 files changed, 18 insertions(+), 0 deletions(-)
> >>>>
> >>>> diff --git a/cpus.c b/cpus.c
> >>>> index fc3f222..29b1070 100644
> >>>> --- a/cpus.c
> >>>> +++ b/cpus.c
> >>>> @@ -254,6 +254,10 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
> >>>> pthread_sigmask(SIG_BLOCK, NULL, &set);
> >>>> sigdelset(&set, SIG_IPI);
> >>>> sigdelset(&set, SIGBUS);
> >>>> +#ifndef CONFIG_IOTHREAD
> >>>> + sigdelset(&set, SIGIO);
> >>>> + sigdelset(&set, SIGALRM);
> >>>> +#endif
> >>>
> >>> I'd prefer separate qemu_kvm_init_cpu_signals in the !IOTHREAD
> >>> section.
> >>
> >> You mean to duplicate qemu_kvm_init_cpu_signals for both configurations?
> >
> > Yes, so to avoid #ifdefs spread.
>
> Would exchange some #ifdefs against ifndef _WIN32. Haven't measured the
> delta though.
>
> >
> >>>> +
> >>>> +#ifndef CONFIG_IOTHREAD
> >>>> + if (sigismember(&chkset, SIGIO) || sigismember(&chkset, SIGALRM)) {
> >>>> + qemu_notify_event();
> >>>> + }
> >>>> +#endif
> >>>
> >>> Why is this necessary?
> >>>
> >>> You should break out of cpu_exec_all if there's a pending alarm (see
> >>> qemu_alarm_pending()).
> >>
> >> qemu_alarm_pending() is not true until the signal is actually taken. The
> >> alarm handler sets the required flags.
> >
> > Right. What i mean is you need to execute the signal handler inside
> > cpu_exec_all loop (so that alarm pending is set).
> >
> > So, if there is a SIGALRM pending, qemu_run_timers has highest
> > priority, not vcpu execution.
>
> We leave the vcpu loop (thanks to notify_event), process the signal in
> the event loop and run the timer handler. This pattern is IMO less
> invasive to the existing code, specifically as it is about to die
> long-term anyway.
You'll probably see poor timer behaviour on smp guests without iothread
enabled.
^ permalink raw reply
* Re: [PATCH] ASoC: Tegra: Harmony: Remove redundant !!
From: Mark Brown @ 2011-02-01 14:14 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-tegra, alsa-devel, lrg
In-Reply-To: <1296496817-10128-1-git-send-email-swarren@nvidia.com>
On Mon, Jan 31, 2011 at 11:00:17AM -0700, Stephen Warren wrote:
> gpio_set_value* should accept logic values not just 0 or 1. The WM8903 GPIO
> driver has been fixed to work this way, so remove the redundant !!
> previously required when it didn't accept values >1.
Applied thanks.
^ permalink raw reply
* [PATCH v2 3/3] isimodem: header updates for ISI2.5
From: Jessica Nilsson @ 2011-02-01 14:13 UTC (permalink / raw)
To: ofono
In-Reply-To: <cover.1296569048.git.jessica.j.nilsson@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 7267 bytes --]
---
drivers/isimodem/debug.c | 132 ++++++++++++++++++++++++++++++++++++++++++++
drivers/isimodem/debug.h | 9 +++
drivers/isimodem/mtc.h | 38 +++++++++++++
drivers/isimodem/version.h | 26 +++++++++
4 files changed, 205 insertions(+), 0 deletions(-)
create mode 100644 drivers/isimodem/version.h
diff --git a/drivers/isimodem/debug.c b/drivers/isimodem/debug.c
index 3d667b4..8b5fa16 100644
--- a/drivers/isimodem/debug.c
+++ b/drivers/isimodem/debug.c
@@ -165,6 +165,138 @@ const char *mtc_modem_state_name(enum mtc_modem_state value)
return "MTC_<UNKNOWN>";
}
+const char *mce_message_id_name(enum mce_message_id value)
+{
+ switch (value) {
+ _(MCE_MODEM_STATE_IND);
+ _(MCE_MODEM_STATE_QUERY_REQ);
+ _(MCE_MODEM_STATE_QUERY_RESP);
+ _(MCE_RF_STATE_REQ);
+ _(MCE_RF_STATE_RESP);
+ _(MCE_RF_STATE_IND);
+ _(MCE_RF_STATE_QUERY_REQ);
+ _(MCE_RF_STATE_QUERY_RESP);
+ _(MCE_POWER_OFF_REQ);
+ _(MCE_POWER_OFF_RESP);
+ }
+ return "MCE_<UNKNOWN>";
+}
+
+const char *mce_modem_state_name(enum mce_modem_state value)
+{
+ switch (value) {
+ _(MCE_NORMAL);
+ _(MCE_LOCAL);
+ _(MCE_SW_RESET);
+ _(MCE_POWER_OFF);
+ }
+ return "MCE_<UNKNOWN>";
+}
+
+const char *mce_status_info(enum mce_status_info value)
+{
+ switch (value) {
+ _(MCE_OK);
+ _(MCE_FAIL);
+ _(MCE_ALREADY_ACTIVE);
+ _(MCE_TRANSITION_ONGOING);
+ }
+ return "MCE_<UNKNOWN>";
+}
+
+const char *mce_rf_state_name(enum mce_rf_state value)
+{
+ switch (value) {
+ _(MCE_RF_OFF);
+ _(MCE_RF_ON);
+ }
+ return "MCE_RF<UNKNOWN>";
+}
+
+const char *uicc_status_name(uint8_t value)
+{
+ switch (value) {
+ /* Request performed successfully */
+ _(UICC_STATUS_OK);
+ /* Error in performing the command */
+ _(UICC_STATUS_FAIL);
+ /* Status is Unknown */
+ _(UICC_STATUS_UNKNOWN);
+ /* Server is not ready */
+ _(UICC_STATUS_NOT_READY);
+ /* Server start up is completed */
+ _(UICC_STATUS_START_UP_COMPLETED);
+ /* Server is shutting down */
+ _(UICC_STATUS_SHUTTING_DOWN);
+ /* Smart card is not ready */
+ _(UICC_STATUS_CARD_NOT_READY);
+ /* Smart card is ready */
+ _(UICC_STATUS_CARD_READY);
+ /* Smart card is disconnected */
+ _(UICC_STATUS_CARD_DISCONNECTED);
+ /* Smart card is not present */
+ _(UICC_STATUS_CARD_NOT_PRESENT);
+ /* Smart card has been rejected */
+ _(UICC_STATUS_CARD_REJECTED);
+ /* Application is active */
+ _(UICC_STATUS_APPL_ACTIVE);
+ /* Application is not active */
+ _(UICC_STATUS_APPL_NOT_ACTIVE);
+ /* PIN verification used */
+ _(UICC_STATUS_PIN_ENABLED);
+ /* PIN verification not used */
+ _(UICC_STATUS_PIN_DISABLED);
+ }
+ return "UICC_STATUS<UNKNOWN>";
+}
+
+const char *uicc_subblock_name(uint8_t value)
+{
+ switch (value) {
+ _(UICC_SB_SHUT_DOWN_CONFIG);
+ _(UICC_SB_CARD_STATUS);
+ _(UICC_SB_CARD_INFO);
+ _(UICC_SB_CARD_REJECT_CAUSE);
+ _(UICC_SB_CLIENT);
+ _(UICC_SB_APPL_DATA_OBJECT);
+ _(UICC_SB_APPLICATION);
+ _(UICC_SB_APPL_INFO);
+ _(UICC_SB_APPL_STATUS);
+ _(UICC_SB_FCP);
+ _(UICC_SB_FCI);
+ _(UICC_SB_CHV);
+ _(UICC_SB_PIN);
+ _(UICC_SB_PIN_REF);
+ _(UICC_SB_PUK);
+ _(UICC_SB_PIN_SUBST);
+ _(UICC_SB_PIN_INFO);
+ _(UICC_SB_APPL_PATH);
+ _(UICC_SB_SESSION);
+ _(UICC_SB_FILE_DATA);
+ _(UICC_SB_APDU);
+ _(UICC_SB_TRANSPARENT_READ);
+ _(UICC_SB_TRANSPARENT_UPDATE);
+ _(UICC_SB_TRANSPARENT);
+ _(UICC_SB_LINEAR_FIXED);
+ _(UICC_SB_CYCLIC);
+ _(UICC_SB_TERMINAL_PROFILE);
+ _(UICC_SB_TERMINAL_RESPONSE);
+ _(UICC_SB_ENVELOPE);
+ _(UICC_SB_POLLING_SET);
+ _(UICC_SB_REFRESH);
+ _(UICC_SB_AID);
+ _(UICC_SB_REFRESH_RESULT);
+ _(UICC_SB_APDU_ACTIONS);
+ _(UICC_SB_OBJECT_ID);
+ _(UICC_SB_STATUS_WORD);
+ _(UICC_SB_APDU_SAP_INFO);
+ _(UICC_SB_ACCESS_MODE);
+ _(UICC_SB_RESP_INFO);
+ _(UICC_SB_APDU_SAP_CONFIG);
+ }
+ return "UICC_<UNKNOWN>";
+}
+
const char *sms_isi_cause_name(enum sms_isi_cause value)
{
switch (value) {
diff --git a/drivers/isimodem/debug.h b/drivers/isimodem/debug.h
index e149c2c..db01f04 100644
--- a/drivers/isimodem/debug.h
+++ b/drivers/isimodem/debug.h
@@ -27,6 +27,7 @@
#include "ss.h"
#include "mtc.h"
#include "sms.h"
+#include "uicc.h"
#include "sim.h"
#include "info.h"
#include "call.h"
@@ -41,6 +42,14 @@ const char *ss_ussd_type_name(enum ss_ussd_type value);
const char *mtc_isi_cause_name(enum mtc_isi_cause value);
const char *mtc_message_id_name(enum mtc_message_id value);
const char *mtc_modem_state_name(enum mtc_modem_state value);
+const char *mce_rf_state_name(enum mce_rf_state value);
+
+const char *mce_message_id_name(enum mce_message_id value);
+const char *mce_modem_state_name(enum mce_modem_state value);
+const char *mce_status_info(enum mce_status_info value);
+
+const char *uicc_subblock_name(uint8_t value);
+const char *uicc_status_name(uint8_t value);
const char *sms_gsm_cause_name(enum sms_gsm_cause value);
const char *sms_isi_cause_name(enum sms_isi_cause value);
diff --git a/drivers/isimodem/mtc.h b/drivers/isimodem/mtc.h
index 2db3e94..57e5040 100644
--- a/drivers/isimodem/mtc.h
+++ b/drivers/isimodem/mtc.h
@@ -27,9 +27,47 @@ extern "C" {
#endif
#define PN_MTC 0x15
+#define PN_MODEM_MCE 0xC2
#define MTC_TIMEOUT 5
#define MTC_STATE_REQ_TIMEOUT (6 + 5)
+enum mce_message_id {
+ MCE_MODEM_STATE_IND = 0x00,
+ MCE_MODEM_STATE_QUERY_REQ = 0x01,
+ MCE_MODEM_STATE_QUERY_RESP = 0x02,
+ MCE_RF_STATE_REQ = 0x03,
+ MCE_RF_STATE_RESP = 0x04,
+ MCE_RF_STATE_IND = 0x05,
+ MCE_RF_STATE_QUERY_REQ = 0x06,
+ MCE_RF_STATE_QUERY_RESP = 0x07,
+ MCE_POWER_OFF_REQ = 0x08,
+ MCE_POWER_OFF_RESP = 0x09
+};
+
+enum mce_rf_state {
+ MCE_RF_OFF = 0x00,
+ MCE_RF_ON = 0x01
+};
+
+enum mce_status_info {
+ MCE_OK = 0x00,
+ MCE_FAIL = 0x01,
+ MCE_ALREADY_ACTIVE = 0x06,
+ MCE_TRANSITION_ONGOING = 0x16
+};
+
+enum mce_modem_state {
+ MCE_NORMAL = 0x00,
+ MCE_LOCAL = 0x01,
+ MCE_SW_RESET = 0x80,
+ MCE_POWER_OFF = 0x81
+};
+
+enum mce_isi_action {
+ MCE_START = 0x03,
+ MCE_READY = 0x04
+};
+
enum mtc_isi_cause {
MTC_OK = 0x00,
MTC_FAIL = 0x01,
diff --git a/drivers/isimodem/version.h b/drivers/isimodem/version.h
new file mode 100644
index 0000000..9b0a993
--- /dev/null
+++ b/drivers/isimodem/version.h
@@ -0,0 +1,26 @@
+
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) ST-Ericsson SA 2011.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+enum isi_version {
+ ISI_20 = 0,
+ ISI_25 = 1
+};
--
1.7.3.5
^ permalink raw reply related
* [PATCH v2 2/3] udev: u8500 support and style fix
From: Jessica Nilsson @ 2011-02-01 14:13 UTC (permalink / raw)
To: ofono
In-Reply-To: <cover.1296569048.git.jessica.j.nilsson@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
---
plugins/udev.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/plugins/udev.c b/plugins/udev.c
index ce1efe6..49b5eb8 100644
--- a/plugins/udev.c
+++ b/plugins/udev.c
@@ -185,7 +185,8 @@ static void add_hso(struct ofono_modem *modem,
devnode = udev_device_get_devnode(udev_device);
if (g_str_has_suffix(type, "Application") == TRUE)
- ofono_modem_set_string(modem, APPLICATION_PORT, devnode);
+ ofono_modem_set_string(modem, APPLICATION_PORT,
+ devnode);
else if (g_str_has_suffix(type, "Control") == TRUE)
ofono_modem_set_string(modem, CONTROL_PORT, devnode);
} else if (g_str_equal(subsystem, "net") == TRUE) {
@@ -636,6 +637,8 @@ done:
add_nokia(modem, udev_device);
else if (g_strcmp0(driver, "isiusb") == 0)
add_isi(modem, udev_device);
+ else if (g_strcmp0(driver, "u8500") == 0)
+ add_isi(modem, udev_device);
else if (g_strcmp0(driver, "n900") == 0)
add_isi(modem, udev_device);
else if (g_strcmp0(driver, "gobi") == 0)
--
1.7.3.5
^ permalink raw reply related
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.